General

Previous versions of SingleStoreDB used available RAM for pricing and to define the boundary between free and enterprise licenses. If you already have one of these RAM-based licenses, you can continue to use it when upgrading to newer versions of MemSQL; however, MemSQL 6.7.13 and later now support licenses based on the concept of units. All new licenses generated in the SingleStore Customer Portal will be unit-based licenses.

A unit is a combination of compute (8 vCPU or less) and RAM (32 GB or less) and only applies to hosts that run leaf nodes in a cluster. Note: SingleStoreDB counts the number of virtual cores available to a processor, regardless of whether hyper-threading is enabled or not.

The size of the host (physical or virtual) determines how many license units will be counted when you add leaf nodes to that host to your cluster. The total license units for a host are calculated by taking the total RAM of the host divided by 32, or the total number of vCPUs divided by 8, and rounding up. Whichever is the greater value (RAM or vCPU) is the number of potential license units on that host. Because this only applies to leaf nodes in your cluster, aggregator nodes are not part of the license unit calculation and can be deployed on any quantity or size of hosts that meet the minimum hardware requirements for installation.

To help understand how license units are calculated, the following table provides examples of how many license units would be counted for various AWS EC2 instance types:

You can artificially constrain or limit the number of license units to a subset of the resources available by lowering the resources available to a host that you are deploying a leaf node onto. For example, if you have a physical machine with 16 vCPU and 48 GB of RAM, SingleStoreDB will consider you to have two potential license units if you used that machine as a host. To artificially constrain your capacity, deploy SingleStoreDB onto a virtual machine instead with fewer resources to lower your license unit count per host (which would be considered the virtual machine).

SingleStoreDB is a standalone distributed database that is compatible with MySQL client software.

SingleStoreDB is not a storage engine or other component of MySQL, nor is MySQL a component of SingleStoreDB, and the SingleStoreDB and MySQL servers do not share any code. The SingleStoreDB server includes its own storage engine and SQL-based execution engine built around scalable distributed execution, lock-free data structures, and machine code generation.

Users use MySQL client software to connect to the SingleStoreDB server. SingleStoreDB uses the same wire protocol as MySQL and supports similar SQL syntax as MySQL for compatibility with MySQL client software.

For compatibility with MySQL client software, SingleStoreDB reports the version engine variable as 5.5.8. Client drivers look for this version to determine how to interact with the server.

This is not the SingleStoreDB server version. The SingleStoreDB server version can be found in the memsql_version engine variable, which can be queried like SELECT @@memsql_version.

As a result, certain MySQL clients may display the server version as 5.5.8, even though this is not the SingleStoreDB version. For example, the mysql command line client may display

Server version: 5.5.8 MemSQL source distribution (compatible; MySQL Enterprise & MySQL Commercial)

when you connect to SingleStoreDB.

No. The SingleStoreDB and MySQL servers are separate database engines which do not share any code, so security issues in the MySQL server are not applicable to SingleStoreDB.

SingleStoreDB implements the MySQL wire protocol in order to provide compatibility with MySQL client software. A part of this compatibility involves reporting a MySQL version number as described above. As a result of this, numerous third-party security scanners that use the reported version number as a vulnerability marker report false positives, as they’re looking at a version number, not at the actual presence of a vulnerability. Our engineering team as well as a third-party security analysis have confirmed that SingleStoreDB is not susceptible to these MySQL vulnerabilities.

SingleStoreDB provides both in-memory row-based and on-disk column-based stores.

The in-memory row store:

The on-disk column store:

SingleStoreDB’s storage engine uses multi-version concurrency control with lock-free skip lists and lock-free hash tables which allow highly concurrent reads and writes at very high throughput. Reads in SingleStoreDB are never blocked, but updates to the same row can conflict with logical locks.

Two common techniques for leveraging large amounts of memory in traditional databases are storing data files on a “ramdisk” or running a disk-based storage engine with a large buffer pool. For example, MySQL performs much better with InnoDB configured to use a large buffer pool.

While running an existing storage engine like InnoDB in memory can alleviate some of the bottlenecks involved with disk, SingleStoreDB has four distinguishing memory-optimized features that enable it to perform significantly better than disk-based storage engines running in memory:

SingleStoreDB excels at real-time and high throughput query use cases. It is a general purpose database for running both transactional and analytic workloads. However, there are use cases which SingleStoreDB is not designed to run. Some of these are listed below: