Indeed they did plan ahead very well. It's no surprise if Postgres is doing so well this days.
Maybe time to change habits on table naming? I'm still on the fence myself but there are interesting arguments there.
Databases do improve and provide more "cache like" features, but such caches are still needed for the time being.
This is indeed an area which could be better handled in SQLite. It needs to be carefully checked when introduced in a project.
Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.
Interesting, it looks like index scans in your databases can have surprising performance results with SSDs.
An oldie but a goodie about SQL injection. Does a good job getting the overall picture of this particular security plague.
Matrix.org - How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver
Wow, this was a really bad index corruption indeed.
This is indeed a metaphor which should be more common in enterprise software.
Looks like a good resource to better understand indices in relational databases.
Indeed, more metadata in your database can be a life saver.
A reminder that writing on disks is a longer process than you could suspect. Many things can go wrong on that chain.
It shows unexpected results in its measurements. It also highlights the importance of proper settings for your database system.
A nice extension for Postgres allowing to ease the protection of personal information.
Good overview on how the databases landscape evolved the past year.
Interesting explanation of a research paper exploring the possibility of a faster SQLite by focusing on async I/O.
This is a nice view into how a query planner roughly works and a nice algorithm which can be used internally to properly estimate the number of distinct values in a column.
If you wonder how the protocol is designed and how the actual implementation works, this is a nice introduction. Clearly it's helped by the size of that program which is fairly small.
A good reminder that I should probably evaluate DuckDB for some of my tooling.
I definitely like the approach of having vectorisation in the RDBMS directly. This is one less moving part, less complexity at the application level to synchronize everything together. In this case it's a Postgres extension.