It seems easy, but actually managing files as a database safely is actually very hard. Especially ensuring atomicity.

Portability is a problem as well.

You do not need an SQL database however, there are others available.

Of course these questions are hard and if you are asking them you may need a general db.

The whole industry is wrapped up in these bizarre ideas that for the slightest requirement they are going to add just one more abstraction layer and it will do everything and the kitchen sink. But sometimes the requirement is simple and doesn't deserve solutions to anticipated problems and other times it does and is worth looking for an existing solution. Rarely the problem is complex and deserves a custom solution and then one should probably make a new startup for the one yak shave, etc..

The technology is only part of the problem. If you aren't happy with any existing database, throwing even more technology at it is definitely not going to help - statistically speaking. You're up against millions of engineering hours in this space.

At some point, we need to get up from the computer and go talk to the business and customer about their problem in terms that don't involve anything more sophisticated than excel spreadsheets. There is definitely some aspect you missed if you think you need to build a fully custom technology vertical to get them to pay for a solution.

Of course, all of this advice is pointless if what you are doing is for amusement or as a hobby. I think a lot of arguments about technology would be diffused if we prefaced with our intended applications.

> You're up against millions of engineering hours in this space.

Tangential, but the fact that many orgs choose to not use native DB features like foreign key constraints, saying that “they’ll handle it in application code,” has always seemed like the pinnacle of hubris to me. You’re going to ignore some of the most battle-tested pieces of technology, and recreate it poorly instead? Quite the decision.

While there are valid reasons to not want to use FKCs, IME much of the time when you peel apart the layers of why someone chose not to, you find that they made several erroneous assumptions that led them to that conclusion. Other times, it’s that they simply didn’t know something existed, because they never read the docs. Windowing functions are a good example: RDBMS can do quite a bit of manipulation to data, rather than just sending huge result sets and having you parse them. There are trade-offs, of course, but you should at least know that it’s even possible before choosing to ignore it.

What I want is sqlite but in native Java.

Using files instead of SQLite very much is NIH. Good luck not corrupting or losing your data.

The Gang Learns About Fsync.

If only that’s all it took.

It’s certainly something you can invent yourself in a cross-platform way, sure.

I thought we were talking about NIH, H is for here. If you can't scope your requirements then obviously you need to import something a bit larger than the whole world to solve the whole world's problems.