Does vsql have goals beyond sqlite?

[Avey777]

Although sqlite is very good, I hope that vsql can completely surpass sqlite in terms of multi-threading

[elliotchance]

Depends what you define as multithreading. If you mean multiple threads mutating the database at the same time, then yes, vsql already surpasses sqlite3 since that's not possible in sqlite3. If you mean in terms of concurrent (or even single) threaded read performance, vsql is obvious slower.

The goals of the project are:

1. Be a native one file database for V applications. This not only requires one less externally compiled dependency, it also has tight integration with V, such as wiring up custom functions at runtime, defining virtual tables and using V's native ORM syntax.
2. Follow the actual SQL standard. I know at lot of databases claim to be compatible - and for the most part they are (PostgreSQL is probably the closest) - however, the truth is that over the years every engine has had to add custom syntax and hacks to either get around features that didn't exist in the standard at the time or were just too annoying to actually use. Some small examples of this are the LIMIT clause or NOW function. I believe the SQL standard is rich enough that we can just follow it and avoid a lot of of the arguments around the the "right" or "best" way to do something.
3. Maintained by the V community. Sounds obvious, but it's worth noting because some people aren't interested in building applications that use a database but rather would prefer to work on a SQL database itself in V, and there is a ton to do.

The non-goals of the project are:

1. To make a high performance database for embedded systems (or really any system). Systems with very slow CPUs should use the more efficient sqlite3 and large insatnces should use battle tested databases like PostgreSQL.
2. Provide longterm API and feature set stability. Established databases have to be very careful with changing or removing even the most nuanced features and syntax as the engine can be deployed in many applications. I want vsql to not have to promise the same API forever, and small changes are incurred on developers so the project can more forward and improve. You shouldn't be using vsql for your mission critical anything.

As a side not, vsql is very well tested and benchmarked so it can also be seen as a good complex project to testing language syntax and performance changes, maybe.

In closing, I don't think there is a "perfect databaae" but I do think vsql could find a niche in the intersection of what it offers above. At the very least, I've got a lot of fun out of building it. Even if nobody ever uses it I still learned a lot.