Valentina DB

We’re using PostgreSQL for many years for our backend applications. It serves hundreds of queries a second, is rock solid and has any feature one can possibly think of (which is not always a good thing, I must add).

However, it also can get complex and when the data volume grows, it sometimes can become slow. Because it has so many features and configuration options, it’s hard to “master it” without diving really deep into the underlying architecture.

Since we also use Xojo for some auxiliary apps, I noticed the Valentina product line a while ago, but I always discarded it as ancient and targeted more toward fat client Desktop apps with strong reporting needs.

So yesterday I evaluated Valentina server and imported a few very big tables into it. I was suprised to see that VServer was faster than PostgreSQL in almost any respect. I added a “IndexByWords” option to one of the tables with roughly 10 million records (a logging table) and did some fulltext searches. It can handle any query below 100ms, no matter what I throw at it. There are some nice optimization features (like the zero-space RecID) and true 1-bit booleans. Also, “links”, which are kind of a replacement for traditional Foreign Keys, make working with it a breeze. It’s almost zero config and has a built-in REST API, and recently added DuckDB as an engine.

I’m trying to contain my excitement a bit and wanted to ask if anyone has real productions experience with Valentina, preferably in a server environment with 50-100 concurrent connections and a high query volume (i.e. serving a web backend). Any insights appreciated!

1 Like

It’s been a long time since I looked at ValentinaDB but if I remember correctly their own database engine ( which is what I think you’re referring to above ) didn’t support transactions.

Right, I discovered that yesterday after my post. Here’s my current collection of +/-'s:

Pros:

  • IndexByWord
  • Links (zero space foreign keys)
  • RecID (zero space primary key)
  • Query Pool
  • Very fast
  • Decent native GUI (Studio)
  • Columnar storage
  • REST API
  • CREATE TYPEs
  • Stored Procs incl. JS and Python langs
  • Events
  • Arrays
  • Has three engines: Valentina, DuckDB, SQLite

Cons:

The lack of transactions (probably the reason why it performs so well), CTEs and Geo types rule out Valentina for our use cases, unfortunately.

1 Like

My experience with Valentina was pretty awful during one of their major transitions. I kept getting data corruption and I chased versions for many months trying to get stability. And somehow it was always my fault when I interacted with support. I don’t recommend.

But, this was 10+ years ago. Different era. Different needs. If I recall it was very, very fast. If it suits your needs then go for it. However, there are a ton of good DB’s out there that will scratch your particular itch.

2 Likes

Like many dbs if you just settle for the default configuration of PostgreSQL it will be “adequate”

But it CAN be tuned to be blazing fast
The EnterpriseDB folks might have blog posts on optimization techniques as they are a great vendor of PostgreSQL solutions

2 Likes

Any data store can be fast when it doesn’t have to deal with hard problems like transactions.

1 Like