Your article completely ignores operational considerations: backups, schema changes, replication/HA. As well as security, i.e. your application has full permissions to completely destroy your data file.
Regardless of whether most apps have enough requests per second to "need" a database for performance reasons, these are extremely important topics for any app used by a real business.
The irony isn’t lost on us, trust me. We spent a while debating whether to even publish this one.
But yeah, the page cache point is real and massively underappreciated. Modern infrastructure discourse skips past it almost entirely. A warm NVMe-backed file with the OS doing the caching is genuinely fast enough for most early-stage products.
Definitely appreciate the post and the discussion that has come from it... While I'm still included to just reach for SQLite as a near starting point, it's often worth considering depending on your needs.
In practice, I almost always separate the auth chain from the service chain(s) in that if auth gets kicked over under a DDoS, at least already authenticated users stand a chance of still being able to use the apps. I've also designed auth system essentially abstracted to key/value storage with adapters for differing databases (including SQLite) for deployments...
Would be interested to see how LevelDB might perform for your testing case, in that it seems to be a decent option for how your example is using data.
props for actually publishing it tbh. transparent engineering takes are so rare now, usually its just seo fluff.
weve basically been brainwashed to think we need kubernetes and 3 different databases just to serve a few thousand users. gotta burn those startup cloud credits somehow i guess.
mad respect for the honesty though, actually makes me want to check out db pro when i finally outgrow my flat files.
I'm feel like I could write another post: Do you even need serverless/Cloud because we've also been brainwashed into thinking we need to spend hundreds/thousands a month on AWS when a tiny VPS will do.
You are both right, with the exception that it requires knowledge and taste to accomplish, both of which are in short supply in the industry.
Why setup a go binary and a json file? Just use google forms and move on, or pay someone for a dead simple form system so you can capture and commmunicate with customers.
People want to do the things that make them feel good - writing code to fit in just the right size, spending money to make themselves look cool, getting "the right setup for the future so we can scale to all the users in the world!" - most people don't consider the business case.
What they "need" is an interesting one because it requires a forecast of what the actual work to be done in the future is, and usually the head of any department pretends they do that when in reality they mostly manage a shared delusion about how great everything is going to go until reality hits.
I have worked for companies getting billions of hits a month and ones that I had to get the founder to admit there's maybe 10k users on earth for the product, and neither of them was good at planning based on "what they need".
Serverless is cheap as hell as low volumes. Your tiny VPS can't scale to zero. If you're doing sustained traffic your tiny VPS might win though. The real value in Cloud is turning capex spend into opex spend. You don't have to wait weeks or months to requisition equipment.
> weve basically been brainwashed to think we need kubernetes and 3 different databases just to serve a few thousand users. gotta burn those startup cloud credits somehow i guess.
I don't think it makes any sense to presume everyone around you is brainwashed and you are the only soul cursed with reasoning powers. Might it be possible that "we" are actually able to analyse tradeoffs and understand the value of, say, have complete control over deployments with out of the box support for things like deployment history, observability, rollback control, and infrastructure as code?
Or is it brainwashing?
Let's put your claim to the test. If you believe only brainwashed people could see value in things like SQLite or Kubernetes, what do you believe are reasonable choices for production environments?
Except that eventually you'll find you lose a write when things go down because the page cache is write behind. So you start issuing fsync calls. Then one day you'll find yourself with a WAL and buffer pool wondering why you didn't just start with sqlite instead.
We went through the exact same dilemma with our product [1]. For desktop apps, one-off with a defined support window just feels right.
Users get certainty, and you still have a clear path to future revenue when that window expires.
Subscription makes a lot more sense once you’re in cloud/collaborative territory which we've just entered. Sounds like you landed in a good place with this split.
Hey! Nice to see you have updated the pricing. I really liked the idea behind your product when I first saw it but the pricing was just a non-starter. Getting work to pay for all of my little productivity tools is a PITA and I still have side projects so spending a few bucks on a license every 2-3 years personally is where I find the sweet spot.
Will be trying out DB Pro again in the near future!
I never considered that people want to watch a video in this day and age when they can try the real thing.
Perhaps I've fallen into that trap with the product [1] I'm building. I have a "Live Demo" button on the landing page and thought that would be enough? I'm going to reconsider...
TBH that part of your landing page exhibits some confusing UX. Perhaps it's just me but when I see a UI image with a play button I assume that clicking it is going to play a video, not redirect me to a login page.
I think there’s a big difference in commitment between the level of friction in signing up for a service and spending a couple of min on orienting myself and clicking play and watching the happy path go for 30s.
I started playing World of Warcraft at the same time I was studying database systems at university and had a similar curiosity. Twenty years later the AzerothCore project pretty much satisfies this curiosity, they've done an incredible job reverse engineering the game server and its database.
That’s fascinating. I didn’t realize the WoW server was so database heavy. do you know if the original game logic was implemented mostly in stored procedures, or was it just used for persistence and the engine handled the rules elsewhere?
It's not, no. The data you see in these files is reconstituted from the data that shipped with the game client, but they're not a perfect match for the real data.
The game servers are all C++ and don't use stored procedures for general gameplay management. They do handle inventory management so that item duping is generally not possible, and complex things like cross-server character transfer use stored procedures.
reply