Select Page

Technical Specifications

How can we help with your next project?

Contact us with questions
eXtremeDB General FAQs
Technical Questions
Pricing & Licensing
eXtremeDB for HPC FAQs

eXtremeDB Technical Specifications

Please find quick links to eXtremeDB technical specifications below.  Our online documentation is also an excellent resource.  

Hardware Platforms

Following are the target hardware platforms that eXtremeDB applications can be deployed on:

  • x86, x86_64
  • IA64
  • ARM
  • MIPS
  • PPC
  • Microblaze
  • M68K (Coldfire)
  • SH4
  • TilePro/TileGX
  • Virtually any 32/64-bit platform

Follow this link for more details on platforms support.

Operating Systems and Software Platforms

Host Platforms

Following are the supported platforms for development with eXtremeDB:

  • Linux (Various distributions)
  • Microsoft Windows 2000 and later including RT
  • Solaris
  • HPUX
  • Apple MacOS X
  • QNX 6.x

 Back to Top

Target Platforms

Following are the supported platforms for deploying eXtremeDB applications:

  • Linux (Various distributions)
  • Microsoft Windows 2000 and later including RT
  • SUN Solaris
  • HPUX
  • Apple MacOS X
  • QNX 6.x
  • Lynx Software Technologies LynxOS
  • Arcturus Network’s µClinux
  • Micrium µC/OS
  • Dynalco Controls MicroC/OS
  • eCosCentric eCos
  • PC/OpenSystems LLC NetOS
  • GNU CygWin
  • GNU MinGW32
  • Apple iOS
  • Android
  • Microsoft Azure ThreadX
  • WindRiver VxWorks VxWorks 653 /VxWorks Cert platform
  • Green Hills Software INTEGRITY (10/11)
  • FreeRTOS
  • DeOS

eXtremeDB can also run without an operating system (bare-bones board)

Platform support is also covered in our online documentation.

 Back to Top

Physical Storage

  • RAM The database is stored entirely in RAM. The content of RAM is lost upon restart.
  • NVRAM devices (a RAM device that retains data without applied power. Data survive device restart)
  • Hard-disk drive (HDD)
  • Solid State drive (SSD)
  • Non-volatile ROM device (read-only memory)
  • Hybrid storage (part of the application’s data kept in RAM and part on persistent media)

Physical storage is also covered in our online documentation.

 Back to Top

Data Repositories

 eXtremeDB databases can be located on persistent or transient storage, which can be organized differently and have different capabilities.

Persistent storage devices and their properties

  • Deployment over raw partitions on SSD and hard-disk media that allows the database to be placed on a partition without a file system
  • Deployment over multiple files systems
  • Integrated RAID-0 (striping), RAID-1 ( mirroring ) support
  • Multi-file support is the ability for the database to be spread over multiple separate files (useful when physical storage partitions are small)
  • Support for asynchronous I/O that allows the database to write to the physical media by a thread separate from the committing thread
  • CRC page integrity runtime verifications (used to add security protection)
  • Multiple logging policies
    • Write Ahead Logging policy (REDO_LOG)
    • Immediate Modifications Logging policy (UNDO_LOG)
    • No logging policy (NO_LOG)

Persistent storage is also covered in our online documentation.

 Back to Top

Transient storage devices 

  • Shared memory (the database is shared between multiple processes)
  • Conventional memory (the database is shared between multiple tasks/threads)
  • NVRAM (the database is located on a non-volatile memory device)
  • Transient repositories can be made persistent with optional Transaction Logging capabilities

Transient storage is also covered in our online documentation.

 Back to Top

Other notable capacities include

Logical Database limits

  • Maximum database size – 4GB for the 32-bit, 18.4 exabytes for a 64-bit
  • Maximum number of objects in a single database – unlimited up to the underlying storage size
  • Maximum number of objects in a single class – unlimited up to the underlying storage size
  • Maximum size of a single table (in bytes) – unlimited up to the underlying storage size
  • Maximum number of fields in a single class – 65,535
  • Maximum size of a single object (in bytes) – 4,294,967,295
  • Maximum number of fields in an index – 65,535
  • Maximum number of indexes for a class – 65,535
  • Maximum number of indexes for a database – 65,535
  • Maximum size of a character array – 65,535
  • Maximum size of any other array – 65,535
  • Maximum number of elements in a vector – 65,535
  • Maximum number of elements in a sequence – 18,446,744,073,709,551,616
  • Code size and memory footprint – up from approximately 250K (platform-dependent), 150K for eXtremeDB/rt
  • Stack size – approximately 2K (depending on features)
  • Maximum number of concurrent connections – 65,535

 Back to Top

Database Runtime Limits

  • Code size and memory footprint: up from approximately 250K (platform-dependent), 150K for eXtremeDB/rt
  • Stack size: approximately 2K (depending on features)
  • What is the maximum number of concurrent connections/tasks/processes:  65,535

  Back to Top

Database Backup and export/import capabilities

  • Online incremental backup (low-overhead backup for transient and persistent databases)
  • Online “file” backup (non-blocking backup of persistent databases)
  • One-time export and a subsequent import of the database into a proprietary binary format
  • JSON export/import
  • XML export/import

Data export and import operations, and backup options are also covered in our online documentation.

  Back to Top

Notification events

Notification events allow an application to be informed of various modifications to the database

  • Asynchronous events are activated after the transaction commits.  They are similar to signals, i.e. contextless asynchronous notifications of data modifications
  • Synchronous events. Synchronous event handlers are called within the context of the same thread that caused the event and notifications do carry context


  Back to Top

Development with eXtremeDB


Languages and programming interfaces

      • Native (non-SQL) APIs are available for C/C++, C#, Java , Scala, Python
      • ODBC and JDBC drivers
      • Rest API
      • SQL-89 with extensions
        • SQL APIs are available for C/C++, C#, Java , Python and Rust
        • Stored procedure languages are C/C++, Lua and Python

Supported Data Types

  • Basic C/C++ language data types for C application
    • integers (short/long, signed/unsigned)
    • float (single -precision floating-point type as in C language)
    • double/long double (double-precision floating-point type as in C language)
    • char (signed/unsigned)
    • boolean (stores True or False)
    • structures
    • arrays
    • variable-length strings/VARBINARY/variable-length vectors
    • Most native data types for other programming languages : Python, Java, C#, Lua, and Rust
  • Unicode character and wide-character data
  • Database-specific
    • BLOBs
    • datetime
    • autoid and reference (stores system-generated unique object identifiers and references to unique identifiers)
    • OID (user-generated object identifier)
    • sequence (columnar storage for time series data)
    • nullable (allow the value to be set to the special value NULL)
    • default values
    • compact data layout (limits all internal class references to 16 bit; can meaningfully reduce storage space requirements for resource-constrained systems)

     Back to Top


A database index is a data structure that improves the speed of data retrieval at the cost of additional writes and storage space to maintain it. Different index algorithms are used for different application scenarios.

  • B-tree indexes are used for partial key (wildcard) search, pattern match (regex), ordered retrieval
  • Hash indexes are available for in-memory tables/classes used only for equality comparisons)
  • R-tree used for spacial access
  • KD-tree is another space-partitioning data structure for organizing points in a k-dimensional space
  • Patricia trie used mostly with IP addresses and telephone numbers
  • Trigram used in text searches when the exact spelling of the target object is not known
  • “Voluntary” index. B-tree or hash index support can be turned on/off on at runtime. When turn on the index is built & maintained by eXtremeDB until turned off
  • User-defined indexes allow application-defined key compare functions, including custom hash functions

Watch a short Webinar segment about your index of choice. 

  Back to Top

Database Transactions

A transaction is a unit of work with the database (a single logical operation on the data). Transactions ensure ACID (Atomicity, Consistency, Isolation and Durability) properties and provide scheduling policies for multiple tasks accessing the database simultaneously. Transactions are implemented via transaction managers. eXtremeDB supports

  • MURSIW transaction manager enforces Multiple Read/Single Write concurrent access to the database
  • Exclusive transaction manager allows a single transaction at a time
  • MVCC transaction manager stands for multi-versioning concurrency control, allows concurrent “readers” and “writers”
  • Transaction priorities. Transaction managers schedule transactions based on application-specified priority levels (similar to RTOS task priorities)
  • Several “delayed” transaction commit policies that “group” write transactions together to lower I/O overhead, trading higher performance for lower durability

Back to Top

Debugging capabilities and monitoring

  • The eXtremeDB debug-mode run-time includes numerous traps in the database code, for detection and easy remediation of programming errors
  • For C/C++, the eXtremeDB-generated programming interface avoids void pointers and exploits the type-checking features of the compiler, with programmer mistakes generating a compile-time error
  • eXtremeDB is available with source code, for complete control of the development environment
  • Optional extended tracing ability
  • Runtime diagnostic, performance monitoring and database configuration capabilities via graphical control panel

 Back to Top

Distributed architecture and remote access features

Distributed databases consist of multiple data repositories located in different sites either on the same network or on entirely different networks. The repositories can be stored in multiple physical locations and processing is distributed among multiple database nodes.

Distributed architectures

  • High Availability implement Active master and Passive replica
  • Cluster implements Multi-Master processing
  • Active Replication Fabric supports bidirectional replication between IoT tiers and ability to queue replication during planned/unplanned loss of connection

Remote access

Back to Top