This is not good advice. It's in parts a hyperbolic and unbalanced view:
> Imagine all the wonderful things you could build if you never had to serialize data into SQL queries.
You can do all those "wonderful things" with an RDBMS too, it's just an additional step.
> First, you don’t need multiple front-end servers talking to a single DB, just get a bigger server with more RAM and more CPU if you need it.
You don't "need" that with a single DB too, you can also get a bigger machine. Also, you can use SQLite and Litestream.
> What about indices? Well, you can use in-memory indices, effectively just hash-tables to lookup objects. You don’t need clever indices like B-tree that are optimized for disk latency.
RDMBS provide all kind of indices. You don't need to build them in your code or re-invent clever solutions. They're all there. Optimized and battle-tested over decades.
> You also won’t need special architectures to reduce round-trips to your database.
You don't need "special architectures" at all. With the most simple setup you get thousands to requests per second and sub 5 ms latency. With SQLite even more. No need for async IO, threads scale well enough for most apps. Anyway, async is not a magical thing.
> You don’t need any services to run background jobs, because background jobs are just threads running in this large process.
How does this change when using an RDBMS?
> You don’t need crazy concurrency protocols, because most of your concurrency requirements can be satisfied with simple in-memory mutexes and condition variables.
I trust a proper proven implementation in SQLite or Postgres much more than "simple in-memory mutexes and condition variables". One reason why Rust is so popular is that it's an eye opener when the compiler shows you all your concurrency bugs you never thought you had in your code.
---------------------
RDBMS solve / support may important things the easy way
- normalized data modelling by refs and joins
- querying, filtering and aggregating data
- concurrency
- storage
Re-inventing those is most of the time much harder, error prone and expensive.
---------------------
The simplest, easy and proven way is still to use an RDBMS. Start with SQLite and Litestream if you don't want to manage Postgres, which is a substantial effort, I admit. Or cost factor, although something like Neon / Supabase / ... for small scale is much much much cheaper than the development costs for all the stuff above.
> Imagine all the wonderful things you could build if you never had to serialize data into SQL queries.
You can do all those "wonderful things" with an RDBMS too, it's just an additional step.
> First, you don’t need multiple front-end servers talking to a single DB, just get a bigger server with more RAM and more CPU if you need it.
You don't "need" that with a single DB too, you can also get a bigger machine. Also, you can use SQLite and Litestream.
> What about indices? Well, you can use in-memory indices, effectively just hash-tables to lookup objects. You don’t need clever indices like B-tree that are optimized for disk latency.
RDMBS provide all kind of indices. You don't need to build them in your code or re-invent clever solutions. They're all there. Optimized and battle-tested over decades.
> You also won’t need special architectures to reduce round-trips to your database.
You don't need "special architectures" at all. With the most simple setup you get thousands to requests per second and sub 5 ms latency. With SQLite even more. No need for async IO, threads scale well enough for most apps. Anyway, async is not a magical thing.
> You don’t need any services to run background jobs, because background jobs are just threads running in this large process.
How does this change when using an RDBMS?
> You don’t need crazy concurrency protocols, because most of your concurrency requirements can be satisfied with simple in-memory mutexes and condition variables.
I trust a proper proven implementation in SQLite or Postgres much more than "simple in-memory mutexes and condition variables". One reason why Rust is so popular is that it's an eye opener when the compiler shows you all your concurrency bugs you never thought you had in your code.
---------------------
RDBMS solve / support may important things the easy way
- normalized data modelling by refs and joins
- querying, filtering and aggregating data
- concurrency
- storage
Re-inventing those is most of the time much harder, error prone and expensive.
---------------------
The simplest, easy and proven way is still to use an RDBMS. Start with SQLite and Litestream if you don't want to manage Postgres, which is a substantial effort, I admit. Or cost factor, although something like Neon / Supabase / ... for small scale is much much much cheaper than the development costs for all the stuff above.