Another major feature of SQL Anywhere is the fact so many features are built-in to the database engine, with DDL to match, rather than implemented as external applications. External applications have to go through an interface to get at database data, and by definition the sum total will be fatter and slower: fatter because the external application must include interface logic that is not required if the feature was implemented inside the engine, and slower because no matter how fast an interface is, it is slower than no interface at all.
For example:
High-performance UNLOAD SELECT, missing from Microsoft SQL Server AFAIK, and crudely implemented in Oracle (SPOOL)... no, wait, SPOOL is a SQL*Plus thing, and SQL*Plus is an external application. And I'm thinking SPOOL might not be called "high performance" when millions of rows are involved, I don't know, doesn't matter in this context, it is not built in to the engine.
High-performance LOAD TABLE, crudely implemented in MSS as BULK INSERT, which may just be a shout-out to that funky external application bcp.exe, and missing from Oracle (don't say SQL*Loader, that's another external application).
Perhaps the most extreme example: SQL Anywhere has a built-in HTTP server. Does it work? You bet! iAnywhere Solutions eats its own dog food... iAnywhere Solutions built the SQL Anywhere Monitor using the engine's built-in HTTP server. And the documentation website uses the built-in HTTP server: DocCommentXchange 2.0 Rocks!
This is not just an abstract benefit: Because these features are built-in, you can get at them easily from code you write that also runs inside the engine: your own stored procedures, triggers, events and web services. With other DBMS software, if you want to write a stored procedure that uses a feature implemented externally, you really face an uphill battle... shell out to the OS, anyone?
And now on to another feature: Watcom SQL syntax, the favored dialect inside SQL Anywhere, is cleaner and more ANSI-compatible than, say Transact SQL [barf!]. Oracle's PL/SQL has its fans, it's certainly powerful, but AFAIK it is unique in all the world..world.I am guessing the only parts that are ANSI-compatible are the parts that Oracle forced into the standards document, but that's just me, bitter from my PL/SQL struggles :)
Don't get me started on IBM DB2... it has the most feeble stored procedure SQL syntax on the planet. True story: I worked on a huge conversion from SQL Anywhere to DB2, and the folks on the DB2 side had enormous difficulties making things work (like nested triggers). When the DB2 code finally compiled, it just would not run, no matter how many gigabytes of RAM you threw at the engine. IBM Labs got involved, finally said "not yet available". The project was a failure: DB2 was abandoned, SQL Anywhere lived on (smells like success, but that's just my bias talking).
I've looked at MySQL, really tried, failed... must be stupid... the sum total of my effort was this blog posting: Unpublished MySQL FAQ. Sadly, that is the most popular thing I've ever written... I certainly could make more money as a MySQL consultant, or Oracle, or MSS, or [kak] DB2, anything but SQL Anywhere. That way lies poverty.