July 28, 2009
The Groovy SQL Switch
I’ve now had a chance to talk with Groovy Corporation CEO Joe Ward, and can add to what Groovy advisor Tony Bain wrote about Groovy Corp and its SQL Switch DBMS. Highlights include:
- The Groovy SQL Switch is a memory-centric OLTP DBMS.
- More precisely, a Groovy SQL Switch database is managed in-memory, and is also persisted to disk. (I haven’t talked yet with a Groovy Corp technical person, and hence don’t know about data access methods or other technical particulars beyond that.)
- The Groovy SQL Switch is initially being introduced as an appliance, but will quickly be sold software-only as well.
- The Groovy SQL Switch runs only on Intel XEON processors.
- The Groovy SQL Switch is fully ACID-compliant.
- Groovy positions its SQL Switch both as a freestanding DBMS and, alternatively, as a companion to incumbent DBMS such as MySQL.
- Groovy strongly positions the Groovy SQL Switch as being for “real time” applications.
- Groovy claims SQL Switch has implemented “most” of SQL-92. SQL-99 and stored procedures are SQL Switch futures.
- Other than through speed, Groovy supports its “real time” claim with a publish/subscribe-like capability for continual updating of SQL Switch result sets, via a SQL extension called SELECT FUTURE. I don’t know how this compares with CEP (Complex Event Processing) vendors’ implementations of similar functionality …
- … but of course Groovy believes that the Groovy SQL Switch is much easier to use and implement than a CEP/DBMS combination.
- ETL, administrative, development, and so on tools for the Groovy SQL Switch are being developed by a couple of third parties, one of which is Persistent Systems.
- As you can see from Groovy Corp’s home page, Groovy is planning to announce an OLTP benchmark result for the Groovy SQL Switch on July 30. You can imagine how excited I am by that. 🙂
- Groovy boasts 2 sales to date, both in the Far East — a Singapore bank and an Indian telecom gaming company. (Groovy Corporation got its start in Australia.) I forgot to ask whether the buyers were in production yet.
One obvious concern about Groovy’s approach is RAM cost. If you’re interested in the Groovy SQL Switch, you probably have a large transaction volume, in which case you probably also have a fast-growing database. Absent some kind of manual partitioning, the Groovy SQL Switch currently requires you to have enough RAM to hold that in its entirety. The same comment, of course, is probably true about VoltDB.
Categories: Groovy Corporation, In-memory DBMS, Memory-centric data management, OLTP
Subscribe to our complete feed!
Comments
2 Responses to “The Groovy SQL Switch”
Leave a Reply
[…] being about an awe-inspiring benchmark. That part met my very low expectations, emphasizing how the Groovy SQL Switch massively outperformed MySQL* in a benchmark, and how this supposedly shows the Groovy SQL Switch […]
[…] option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch. But this client’s database is terabyte-scale, so hardware costs could be an issue, as of […]