Deployment notes

Recommendations

Here are some good to know things about deploying Skytable:

• Skytable is under active development. If you do find any rough edges, please open an issue
• The daemon will create a .sky_pid file in its working directory which functions as a PID file and indicates other processes to not use the data directory. If the daemon is somehow forcefully stopped, the file may not be removed. In that case, you should manually remove the file
• Skytable currently has a default limit of 50000 connections on a single daemon instance. This limit can be modified in your configuration.
  note

  Make sure you change the maximum number of connections according to the available system resources to avoid DoS like attacks that may cause your system to crash

• Skytable is inherently multithreaded. As of now, there is no way to stop Skytable from using multiple threads
• The best way to deploy Skytable is as a service (and disabling terminal artwork)

System requirements

Hardware

• For Intel x86/x86_64 based systems, virtually all processors deployed today will run Skytable without any trouble. On a more specific note, Intel processors released after 2001 and AMD based processors released after 2003 are compatible
• For ARM64 based systems, there are no additional requirements

Fun fact

To sum up, if your processor is from this century, it will most likely work fine ;)

Software

No special requirements as of now.

Data migrations

Skytable is backwards compatible with previously released versions. This means that when you move from an older version to a newer release, your data will be automatically migrated. This migration does not need any external intervention, and will be automatically done when the database server is started up.

Exceptions: However, an exception to this is the upgrade from version 0.6 to 0.7. To complete this upgrade, you must run the sky-migrate utility provided in the bundle to migrate your data. Rest assured, the tool will take care of the migration.

Downgrades to earlier versions

Although we strongly do not recommend you to move from a newer version to an earlier version, we understand that such a transition might be required in some cases. However, we do not support going from a newer version to an older version natively (as in the data cannot be read by the earlier version). Instead, you will need to manually export all data from the newer version and then move it back to the earlier version.

The obvious question here is, "Why?" Newer versions might introduce newer data types and models, that cannot be "predicted" or "guessed" at the time of release of earlier versions. For instance, version 0.7.1 introduces the list data type which however didn't exist in earlier releases. The server cannot guess how it can "transform a list into a string."

If you have any questions, we're happy to help! Open an issue here and we'll get back to you.