Remix.run Logo
kabir_daki 12 hours ago

[dead]

tetha 7 hours ago | parent | next [-]

> The real question isn't "do you need a database" but "do you need state" — and often the answer is no.

We have a bunch of these applications and they are a joy to work with.

Funny enough, even if you have a database, if you wonder if you need caches to hold state in your application server, the answer is, kindly, fuck no. Really, really horrible scaling problems and bugs are down that path.

There are use cases to store expensive to compute state in varnish (HTTP caching), memcache/redis (expensive, complex datastructures like a friendship graph), elasticsearch/opensearch (aggregated, expensive full-text search), but caching SQL results in an application server because the database is "slow" beyond a single transaction brings nothing but pain in the future. I've spent so much energy working around decisions born out of simple bad schema design decisions and tuning...

bevr1337 10 hours ago | parent | prev [-]

> The real question isn't "do you need a database" but "do you need state" — and often the answer is no.

This is a solid takeaway and applies to a lot of domains. Great observation

datadrivenangel 8 hours ago | parent [-]

But if you have state, and that state needs to persist between program executions, then for the love of resiliency and all that is robust, consider using a SQL database!