No subject

- As you mentioned, it cannot only do a fixed number of operations per
transaction

- It also cannot touch the same item twice in one transaction.

- It is not type safe, everything is a string, so everything that is
written must be serialized to strings, and everything that is read must
be parsed from strings, which is more complex and also much slower than
simple data serialization. It also requires more exception handling code
and creates a greater potential for software bugs.

- Etcd is only a key/value store, so it does not have a structure
(tables, rows, columns). Therefore, multiple columns belonging to one
key must be either serialized into multiple key/value paris (increasing
the number of operations per transaction) or the columns must be
serialized into one string (increasing complexity due to the additional
parsing)

- It does not support constraints, such as foreign key constraints,
checks of the values that go into it, etc., you could e.g. store a
TCP/IP-Port number of -70,000 just fine, or a duplicate one, while a
DBMS would have prevented such incorrect entries even in the presence of
a bug in LINSTOR code. That makes the data less robust than it would be
when stored in a DBMS.

- It cannot combine entries or their fields, e.g. like an SQL JOIN can,
so that must be coded into our software if required

- We cannot automatically transform it as we can with a DBMS. It cannot
be instructed to "put all values from this table into this other table"
or "change all the values where this condition matches". Transformations
typically require parsing and loading all the affected entries, then
writing our own logic to make any changes, and then serializing and
storing all the entries again.

- It is far less maintainable. Finding, changing or deleting one or
multiple entries, or just fields of some entries, is quite simple if you
can just type in some SQL manually. There is nothing like that in etcd.


It's just marginally better than writing to files (at least it offers
some kind of transactions). But apart from that, put bluntly, it's a bit
like going back to the 1960s.


But to be fair, even supporting multiple SQL databases is not as
carefree as it might seem. I like to jokingly call any database a
NoSQL-database, because none of the SQL databases actually implements
SQL, they all implement a chaotic mix of subsets, supersets and
variations of SQL. I'm tempted to say that SQL doesn't even exist in the
real world, except as an idea in a book that noone ever read after it
was written.
That being said, due to some kind of a miracle, we're still able to run
four different databases with the same database driver in LINSTOR, with
only few conditional changes here and there.

>
> 2. What about future of sql backends? Are you going to focus on etcd
> as main backend, or continue using sql, and leave etcd as an option?
>

It was meant to be an option, not an replacement. However, nothing is
cast in stone in the real world, even changes to technically worse
solutions are very common in the IT world (unfortunately), due to
various reasons.