Optional, Native Database Storage

Flat-file is fast and flexible, but in the few cases when there’s thousands and thousands of records to search through, we do need a database: MySQL (available in most shared hosts) - or even SQLite would do. That’ll make Kirby suitable for ANY project.

Isn’t that already possible with virtual pages?
https://getkirby.com/docs/guide/virtual-pages/content-from-database

Possible, yes, but it still needs a lot of work to create the models and data structures. Would be great if this could be made easier somehow.

Sometimes I have to use another CMS because when a site has 5,000+ users, I need a database. Trying to set everything up manually with Kirby and virtual pages is very hard, and feels like a ‘patch’ on the core. It would be great if we could have an option perhaps per blueprint, where we can choose how pages made with that blueprint get saved - like “storage: sqlite”. Don’t care if it’s an SQL or NoSQL database, as long as it works out-of-the-box.

Okay, got it!

If Kirby use database, then no need for any other CMS - please add this!

a lot of things need to be considered like fake file modified checks, where to store uploaded files if not in folders.
maybe the core could put a file abstraction layer above the File and Dir classes used in classed inheriting from “Model” and these could either use real files, files from connected storages (S3 etc) or connect to a database.

Uploaded files should stay in folders, like they are now - that’s best practice for databases (large blobs in databases are slow). The database table can be set to keep auto-updated ‘created date’ and ‘last modified date’ for its records - which are like ‘created date’ and ‘modified date’ for a page.

We at Kirbyzone could really use an ‘SqlPage’ right now, @Nico! ;-)

Es wäre schön, SqlPage, CsvPage usw. zu haben.

I really love the file based approach but the current disk only solution complicates rolling out larger Kirby sites (especially when downtime is a problem). Supporting a system where we can have two instances of the application running on the same Kirby data would in my opinion be ideal. This can be implemented either by allowing storage abstractions like S3, or GCS for file storage. But the performance hit might be too big for this to work properly without a database to support fast page lookups?

@Syllabi.02.legendes This is not the place for discussions, but there is no reason you can’t have two Kirby instances using the same Kirby data. Just use a symlink or adjust the config to use a different folder.

Would be nice to have that in kirby also create and update out of the box if a sql connection is set would be nice

I feel like UUIDs for pages and files are a good first building block for this.

I’m just now evaluating Kirby for a site and I’m leaning toward using it, so I know my thoughts may not count for much. But the complexity of adding a database capability scares me. I’m attracted to Kirby because it is flat-file and because it is simple.

This would be helpful mainly if one could have all persistent data in database. This would allow Kirby to run on some of the serverless/fly.io style architectures where disks are not persistent.
It would also require cloud storage (like S3) for files and probably whole bunch of other stuff like locking.
It’s probably so big change that it is not worth it. I don’t think adding replacing files with database on same server has big advantages and where it does Virtual Pages are fine solution.