All these comments seem to fuel my suspicion that we in fact shouldn't use databases, because we don't use any of these features. We just use them as external data storage for a single application. And not even that much data, like <10 gigs.

But the updating I would have expected to go more smoothly. If you make a point of using a software dedicated to managing data, I sure as hell would expect an update to go so smooth that I don't have to worry about or even notice it. In reality updates more often than not seem to come with undocumented errors. That is a constant source of frustration for me.

> because we don't use any of these features. We just use them as external data storage for a single application.

You are using it :) Reboot the server where the database runs or suddenly cut off the connection. Unless you have ACID-compatible storage, you'll have malformed data.

Plan for the future and use a database from the start. When your project/company expands and starts to use multiple applications/services (and that inevitably happens), you'll see (one of) the benefits of the database.

> But the updating I would have expected to go more smoothly

I'm not sure what you are talking about. Database updates are one of the smoothest (critical) software updates you'll find, assuming the database has a good track record.

eh the oracle upgrades went awful. But I try to not touch the database at all if I can

Well, oracle is kind of a beast. If all you need is data storage and maybe an index for fast lookup within 10G of data, sqlite will probably do the trick. It is a library, not a server process so you compile it into your app and there is very little ops work to do. As a benefit, you can do many data access patterns that are closer to what you’d do if you wrote the data access code by hand (no network latency etc)