--- /dev/null
+---
+description: |
+ YottaDB is a language-agnostic hierarchical key-value database that
+ scales from small system-on-chip designs to large servers. Languages are supported
+ through \u201Cwrappers\u201D with support currently available for C, Go, M, Perl,
+ and Rust, with support for node.js and Python expected soon. Other wrappers from
+ the community allow YottaDB to be a JSON data store. Octo provides JDBC / SQL-92
+ based access for reporting and analytics with read-write access support coming
+ in 2021. All our work is 100% free / open source.
+layout: stand
+logo: stands/yottadb/logo.png
+new_this_year: |
+ <p>
+ Since FOSDEM 2020, we have added production grade support for JDBC
+ / SQL-92 access to the database for analytics and reporting, as well as production
+ grade support for access from the Rust language.
+ <br>
+ We have made numerous smaller enhancements such as simpler installation, enhanced
+ troubleshooting tools, performance enhancements,
+ and of course (like every software project) bug fixes.
+ </p>
+showcase: |
+ <p>
+ Based on a mature code base (in daily production use since 1986; continuously
+ invested in and evolving since), YottaDB is a language-agnostic hierarchical key-value
+ database to which all common NoSQL and SQL use cases map well. Its robustness, scalability
+ and security are demonstrated by the fact that it is the database of record for
+ some of the largest real-time core-banking applications in the world, as well as
+ a nation scale electronic health record system. In Belgium, it is the database of
+ record for the University of Antwerp library system!
+ </p>
+ <br>
+ <h3>Learn More about YottaDB:</h3>
+ <ul>
+ <li><a href="/stands/yottadb/features">Features</a></li>
+ <li><a href="/stands/yottadb/how_it_works">How It Works?</a></li>
+ <li><a href="/stands/yottadb/use_cases">Use Cases</a></li>
+ <li><a href="/stands/yottadb/success_stories">Success Stories</a></li>
+ </ul>
+themes:
+ - Database engines
+title: YottaDB
+website: https://yottadb.com
+show_on_overview: true
+---
\ No newline at end of file
--- /dev/null
+---
+title: "ACID Properties"
+draft: false
+---
+
+# ACID Properties
+
+YottaDB implements transactions with strong Atomic, Consistent, Isolated, Durable (ACID) properties. Consider application logic to move $100 from a savings account to a checking account, which conceptually consists of the following steps:
+
+ - Validate that the accounts exist, that the requested transfer is permitted, that there is sufficient balance, that the transfer request is authenticated, etc.
+ - Subtract $100 from the savings account.
+ - Add $100 to the checking account.
+ - Compute and debit any applicable service charges.
+ - Create a record to log the transaction.
+
+Consider that application logic executing concurrently with an update to business rules affecting minimum balances and service charges, and a balance inquiry. Each of the three is implemented as an ACID transaction.
+
+**Atomicity** is the property that the entire transaction happens or none of it happens. For example, in the event of a system malfunction, it should not recover to an intermediate state such as between the withdrawal from savings and the deposit to checking.
+
+**Consistency** is the property that the database should never be observable in a state that is inconsistent (the process of course sees its own data that it is manipulating in a transient state).
+
+**Isolation** is the property that each transaction executes and commits as if it were the only transaction active on the system. For example, from the point of view of the database state change, the money-transfer commits either before or after the business rules update, even if the logic for both executes concurrently.
+
+There is a duality between Consistency and Isolation -- as a practical matter, it is not possible to provide strong Consistency without strong Isolation and vice versa. YottaDB provides strong Consistency and Isolation. Strict [Serializability](https://en.wikipedia.org/wiki/Serializability) implies strong Consistency and Isolation, and vice versa.
+
+**Durability** is the property that once a transaction is committed, the database state change it represents is permanent, even if the computer crashes. YottaDB implements Durability by logging each transaction to a journal file, and “hardening” that journal file to non-volatile storage as part of the logic that commits a transaction.
\ No newline at end of file
--- /dev/null
+---
+title: "Business Continuity"
+draft: false
+---
+
+# Business Continuity
+
+While Durability is based on recovering application state from persistent non-volatile storage, business continuity of an application requires recovery of application state even in the face of loss of that non-volatile storage, e.g., the unplanned loss of a data center or a geography. In the event of unplanned loss of a data center or a geography, a mission critical application should continue to be available from another data center.
+
+YottaDB achieves business continuity with real-time replication. Transactions are processed on a single instance for serialization performance (serialization is slower when it the decision making required for strict serialization is distributed over multiple instances). As journal records are written to journal files, those updates are streamed in real time to as many as 16 secondary instances. Each of those 16 secondary instances can stream the updates it receives in real time to 16 more instances (for up to 256 tertiary instances), and so on, without any limit imposed by YottaDB.
+
+In the event of loss of the instance in that primary role, any of the instances to which it is replicating can be switched from a secondary (or tertiary, or other downstream role) to the primary role. When the instance in the original primary role is recovered, it operates in a secondary role, and catches up with transactions processed by the instance that took over the primary role.
+
+Given the strict serialization requirements of demanding applications such as banking core processing, YottaDB provides mechanisms for an application to restore strict serialization after such an outage.
+
+The operation of the primary instance that originates updates is unaffected by the state of any replication connection or secondary instance receiving updates. The instances share no hardware or software resources, and thus one instance is unaffected by any other instance.
+
+---
+**NOTE**
+
+With n instances, it is possible to provide business continuity in the face of at most n-1 unplanned outages. Since the number of instances is always a finite number, absolute business continuity does not exist, and the number of instances becomes a business decision rather than a technical decision resulting from a YottaDB limit.
+
+---
+
+As YottaDB replication replicates only logical update information, network bandwidth use is parsimonious compared to techniques such as storage-mirroring. Furthermore, YottaDB can optionally use the standard zlib compression library to further reduce bandwidth used.
--- /dev/null
+---
+title: "Features"
+draft: false
+---
+
+# Features
+
+## Business Continuity
+
+YottaDB’s business continuity and real-time replication features keep even Internet-scale applications continuously available not just in the face of unplanned events, but also planned events, such as application upgrades and even schema changes.
+
+[Learn More](/stands/yottadb/business_continuity)
+
+## Daemon-less
+
+YottaDB operates using a daemon-less engine. Why?
+
+ - With a daemon, failure of a daemon process stalls the operation of multiple processes and perhaps even multiple applications.
+ - With a daemon, a daemon process typically has to operate with elevated privileges compared to an application process, and furthermore the link between application and daemon must be secured.
+ - Communication between application logic and a database daemon adds latency and increases response times.
+ - A daemon is an additional process that consumes system resources, even if only an incremental amount.
+
+[Learn More](/stands/yottadb/in_memory_engine)
+
+## Security
+
+With a philosophy that complexity is the enemy of security, the simply-explained YottaDB security model is based on the mature and easily understood [user-group-world](https://en.wikipedia.org/wiki/File-system_permissions) permissions for processes to access database files. Security can be further enhanced with layered controls like [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux).
+
+## Multi-Language Database Access
+
+{{< figure src="/stands/yottadb/multi-lang-db-access.svg" width="50%" height="50%">}}
+
+While the historic roots of YottaDB are in the M language, YottaDB extends the tight integration of the language with the database to other languages. As C is the lingua franca of programming languages (in that all programming languages have the ability to call a C API), YottaDB’s C language API extends the database engine to all programming languages. Through the C API, bindings (called "wrappers") exist to natively access YottaDB concurrently also from Go, Perl, and Rust. Community developed wrappers from C++, node.js, and Python are under development and at various levels of usability and maturity, with all expected soon.
+
+[Learn More](/stands/yottadb/hello_world)
+
+## Optimistic Concurrency Control
+
+Unlike most high-end transactional database engines, YottaDB uses Optimistic Concurrency Control (OCC) to implement ACID transactions. Since transactions do not typically collide, optimistic techniques scale up better than pessimistic techniques such as locking.
+
+[Learn More](/stands/yottadb/occ)
+
+## Strongly ACID transactions
+
+ACID transactions are YottaDB's strong suit, and give applications a data source they can rely on.
+
+[Learn More](/stands/yottadb/acid)
\ No newline at end of file
--- /dev/null
+---
+title: "Hello World Examples"
+draft: false
+---
+
+The following sections discuss YottaDB's Multi-Language support via a simple `sayHello` example. Each language uses its own sample program to add a node in the same database. Then the MUPIP EXTRACT command is used to display the contents of that database, successfully showing YottaDB being accessed by different APIs/ wrappers.
+
+## Access from C
+
+YottaDB comes with a [C API](https://docs.yottadb.com/MultiLangProgGuide/cprogram.html) and all you need to use it is the gcc compiler. The `sayhelloC.c` program is downloaded, compiled and run. Notice that it sets a node in the database (the MUPIP EXTRACT command prints database contents):
+
+```bash
+yottadbuser@yottadbworkshop:~$ ls -l
+total 52
+-rw-r--r-- 1 root root 262 Jan 17 2020 sayhelloC.c
+-rwxr-xr-x 1 yottadbuser yottadbuser 47020 Aug 26 14:00 ydbinstall.sh
+yottadbuser@yottadbworkshop:~$ gcc $(pkg-config --libs --cflags yottadb) -o sayhelloC sayhelloC.c -lyottadb
+yottadbuser@yottadbworkshop:~$ ls -l
+total 72
+-rwxr-xr-x 1 yottadbuser yottadbuser 16600 Aug 26 14:41 sayhelloC
+-rw-r--r-- 1 root root 262 Jan 17 2020 sayhelloC.c
+-rwxr-xr-x 1 yottadbuser yottadbuser 47020 Aug 26 14:00 ydbinstall.sh
+yottadbuser@yottadbworkshop:~$ ./sayhelloC
+yottadbuser@yottadbworkshop:~$ mupip extract -format=zwr -label="Hello label" -select=hello -stdout
+Hello label UTF-8
+26-AUG-2020 15:00:13 ZWR
+^hello("C")="Hello, world!"
+%YDB-I-RECORDSTAT, ^hello: Key cnt: 1 max subsc len: 10 max rec len: 13 max node len: 27
+%YDB-I-RECORDSTAT, TOTAL: Key cnt: 1 max subsc len: 10 max rec len: 13 max node len: 27
+yottadbuser@yottadbworkshop:~$
+```
+
+## Access from Go
+
+[Accessing YottaDB from Go](https://docs.yottadb.com/MultiLangProgGuide/goprogram.html) requires the Go yottadb package to be downloaded and installed. The `sayhelloGo.go` program is downloaded, compiled and run. Notice that it too sets a node in the database:
+
+```bash
+yottadbuser@yottadbworkshop:~$ go build sayhelloGo.go
+yottadbuser@yottadbworkshop:~$ ./sayhelloGo
+yottadbuser@yottadbworkshop:~$ mupip extract -format=zwr -label="Hello" -select=hello -stdout
+YottaDB MUPIP EXTRACT /usr/local/lib/yottadb/r130/mupip extract -format=zwr -select=hello -stdout UTF-8
+26-AUG-2020 15:08:23 ZWR
+^hello("C")="Hello, world!"
+^hello("Go")="สวัสดีชาวโลก"
+%YDB-I-RECORDSTAT, ^hello: Key cnt: 2 max subsc len: 11 max rec len: 36 max node len: 44
+%YDB-I-RECORDSTAT, TOTAL: Key cnt: 2 max subsc len: 11 max rec len: 36 max node len: 44
+yottadbuser@yottadbworkshop:~$
+```
+
+## Access from M
+
+YottaDB includes a complete language implementation for M. The `sayhelloM.m` program is downloaded and run (there is no need for a separate compilation step, as there was for C and Go):
+
+```bash
+yottadbuser@yottadbworkshop:~/.yottadb$ ls -l r
+total 4
+-rw-r--r-- 1 yottadbuser yottadbuser 67 Jan 17 2020 sayhelloM.m
+yottadbuser@yottadbworkshop:~/.yottadb$ yottadb -run sayhelloM
+yottadbuser@yottadbworkshop:~/.yottadb$ mupip extract -format=zwr -label="Hello" -select=hello -stdout
+YottaDB MUPIP EXTRACT /usr/local/lib/yottadb/r130/mupip extract -format=zwr -select=hello -stdout UTF-8
+26-AUG-2020 15:12:49 ZWR
+^hello("C")="Hello, world!"
+^hello("Go")="สวัสดีชาวโลก"
+^hello("M")="Приветствую, мир!"
+%YDB-I-RECORDSTAT, ^hello: Key cnt: 3 max subsc len: 11 max rec len: 36 max node len: 44
+%YDB-I-RECORDSTAT, TOTAL: Key cnt: 3 max subsc len: 11 max rec len: 36 max node len: 44
+yottadbuser@yottadbworkshop:~/.yottadb$
+```
+
+## Access from Perl
+
+YottaDB can also be accessed from Perl, which requires the Perl yottadb package to be downloaded and installed, to provide a YottaDB Perl “wrapper”.
+
+The `sayhelloPerl.pl` program is downloaded, marked as an executable and run.
+
+```bash
+yottadbuser@yottadbworkshop:~$ ls -l
+total 3176
+drwxr-xr-x 4 yottadbuser yottadbuser 4096 Aug 26 14:42 go
+-rwxr-xr-x 1 yottadbuser yottadbuser 16600 Aug 26 14:41 sayhelloC
+-rw-r--r-- 1 root root 262 Jan 17 2020 sayhelloC.c
+-rwxr-xr-x 1 yottadbuser yottadbuser 3164920 Aug 26 14:44 sayhelloGo
+-rw-r--r-- 1 yottadbuser yottadbuser 203 Jan 17 2020 sayhelloGo.go
+-rw-r--r-- 1 yottadbuser yottadbuser 86 Aug 26 15:21 sayhelloPerl.pl
+-rwxr-xr-x 1 yottadbuser yottadbuser 47020 Aug 26 14:00 ydbinstall.sh
+yottadbuser@yottadbworkshop:~$ chmod +x sayhelloPerl.pl
+yottadbuser@yottadbworkshop:~$ ./sayhelloPerl.pl.
+yottadbuser@yottadbworkshop:~$ mupip extract -format=zwr -select=hello -stdout
+YottaDB MUPIP EXTRACT /usr/local/lib/yottadb/r130/mupip extract -format=zwr -select=hello -stdout UTF-8
+26-AUG-2020 15:24:21 ZWR
+^hello("C")="Hello, world!"
+^hello("Go")="สวัสดีชาวโลก"
+^hello("M")="Приветствую, мир!"
+^hello("Perl")="Grüẞ Gott Welt"
+%YDB-I-RECORDSTAT, ^hello: Key cnt: 4 max subsc len: 13 max rec len: 36 max node len: 44
+%YDB-I-RECORDSTAT, TOTAL: Key cnt: 4 max subsc len: 13 max rec len: 36 max node len: 44
+yottadbuser@yottadbworkshop:~$
+```
+
+## Access from Rust
+
+YottaDB can also be accessed from Rust, using the YottaDB wrapper for Rust [YDBRust](https://gitlab.com/YottaDB/Lang/YDBRust). Run the `say_hello_rust` example, which will add another node in the database:
+
+```bash
+yottadbuser@yottadbworkshop:~$ git clone --quiet https://gitlab.com/YottaDB/Lang/YDBRust/ # Do this only once for the Acculturation Guide
+yottadbuser@yottadbworkshop:~$ cd YDBRust
+yottadbuser@yottadbworkshop:~/YDBRust$ cargo run --quiet --example say_hello_rust # May take some time the first time
+yottadbuser@yottadbworkshop:~/YDBRust$ mupip extract -format=zwr -select=hello -stdout
+YottaDB MUPIP EXTRACT /usr/local/lib/yottadb/r130/mupip extract -format=zwr -select=hello -stdout UTF-8
+28-AUG-2020 15:34:04 ZWR
+^hello("C")="Hello, world!"
+^hello("Go")="สวัสดีชาวโลก"
+^hello("M")="Приветствую, мир!"
+^hello("Perl")="Grüẞ Gott Welt"
+^hello("Rust")="こんにちは"
+%YDB-I-RECORDSTAT, ^hello: Key cnt: 5 max subsc len: 13 max rec len: 36 max node len: 44
+%YDB-I-RECORDSTAT, TOTAL: Key cnt: 5 max subsc len: 13 max rec len: 36 max node len: 44
+yottadbuser@yottadbworkshop:~/YDBRust$
+```
--- /dev/null
+---
+title: "How It Works"
+draft: false
+---
+
+# How It Works
+
+## Data Structure: Key-Value Tuples
+
+The fundamental core data structure provided by YottaDB is key-value tuples.
+
+Following is a set of key-value tuples:
+
+```
+["Capital","Belgium","Brussels"]
+["Capital","Thailand","Bangkok"]
+["Capital","USA","Washington, DC"]
+```
+
+Each of the above tuples is called a `node`.
+In an *n*-tuple, the first *n*-1 items are keys, and the last item is the value associated with the keys.
+Data in YottaDB is always ordered according to the keys.
+
+YottaDB itself assigns no meaning to the data in each node. But using meaningful keys improves application maintainability.
+
+For example:
+
+```
+["Capital","Belgium","Brussels"]
+["Capital","Thailand","Bangkok"]
+["Capital","USA","Washington, DC"]
+["Population","Belgium",1367000]
+["Population","Thailand",8414000]
+["Population","USA",325737000]
+```
+
+As YottaDB assigns no inherent meaning to the keys or values, its key value structure lends itself to implementing Variety.
+
+For example, if an application wishes to add historical census results under “Population”, the following is a perfectly valid set of tuples:
+
+```
+["Capital","Belgium","Brussels"]
+["Capital","Thailand","Bangkok"]
+["Capital","USA","Washington, DC"]
+["Population","Belgium",1367000]
+["Population","Thailand",8414000]
+["Population","USA",325737000]
+["Population","USA",17900802,3929326]
+["Population","USA",18000804,5308483]
+…
+["Population","USA",20100401,308745538]
+```
+
+In the above example, the application designer has chosen to represent date in the form `yyyymmdd`.
+
+The `first key` is called a `variable`, and the remaining keys are called `subscripts`,e.g., Captial("Belgium")="Brussels".
+
+The set of all nodes under a variable is called a `tree` (so in the example, there are two trees, one under Capital and the other under Population).
+The set of all nodes under a variable and a leading set of its subscripts is called a `subtree` (e.g., Population(“USA”) is a subtree of the Population tree).
+
+With this representation, the Population tree can be written as follows:
+
+```
+Population("Belgium")=1367000
+Population("Thailand")=8414000
+Population("USA")=325737000
+Population("USA",17900802)=3929326
+Population("USA",18000804)=5308483
+…
+Population("USA",20100401)=308745538
+```
+
+And visualized thus:
+
+
+
+## Persistence
+
+In YottaDB, persistence is a property of a variable, visible in the variable name. Prefixing a variable name with a caret(^) makes its data persist beyond the lifetime of a process.
+
+Shared, persistent nodes in a database are called global variable nodes. Nodes that are private to a process with the lifetime of the process are called local variable nodes.
+
+## Transaction Processing
+
+YottaDB implements transactions with strong Atomic, Consistent, Isolated, Durable ([ACID](https://en.wikipedia.org/wiki/ACID)) properties.
\ No newline at end of file
--- /dev/null
+---
+title: "In-Memory Engine"
+draft: false
+---
+
+# In-Memory Engine
+
+At the core of YottaDB is a daemon-less key-value database engine that executes within the address space of the application process, which makes in-memory calls to a YottaDB API. Combining the database engine and application logic in a single process yields several benefits:
+
+## Robustness
+
+A simpler architecture means that in the event of abnormal process termination or other process failure, the other processes of the application can continue. With a daemon, failure of a daemon process stalls the operation of multiple processes and perhaps even multiple applications.
+
+## Security
+
+Complexity is the enemy of security. With YottaDB’s daemon-less architecture, the security model is based on the mature, clearly documented, and well understood user-group-world permissions for processes to access database files, and is amenable to additional layered access controls such as [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) or [AppArmor](https://gitlab.com/apparmor/apparmor).
+
+## Simplicity
+
+The first process to open a database file sets up the control structures to manage it, and the last process to close the file cleans up the control structures. There is no daemon to start, stop, or tune.
+
+## Scalability
+
+With YottaDB’s database engine, processes cooperate with one another to manage the database, and the achievable throughput is limited by the underlying computing platform, rather than the potential single-point bottleneck of a daemon.
+
+## Multi-Language Database Access
+
+With the database engine in a shared library that executes within the address space of each process, application developers are free to develop applications in the language of their choice.
\ No newline at end of file
--- /dev/null
+---
+title: "Optimistic Concurrency Control"
+draft: false
+---
+
+# Optimistic Concurrency Control
+
+Unlike most high-end transactional database engines, YottaDB uses [Optimistic Concurrency Control](http://daslab.seas.harvard.edu/reading-group/papers/kung.pdf) (OCC) to implement [ACID](https://en.wikipedia.org/wiki/ACID) transactions. Since transactions do not typically collide, optimistic techniques scale up better than other techniques. OCC and the daemon-less architecture reinforce each other to provide the extreme level of scalability that YottaDB users have come to expect.
+
+## How YottaDB OCC Works
+
+Every database records a transaction number in its file header. Each database block header records the database transaction number when that block was last updated. When a process is inside a transaction:
+
+ - The database engine tracks the file and block number of each database block read, and the transaction number of that block. Since a block to be updated must first be read, this list includes blocks to be updated.
+ - When application logic updates the database, the update is retained in process-private memory and does not update the database. The update is visible to subsequently application logic within the process, but is not visible to any other process until the transaction commits.
+ - When the application logic signals that it is ready to commit the transaction, the database engine checks whether any block read within the transaction has a higher transaction number than that it has recorded. If none has — the typical case — the engine commits the transaction.
+ - If even one block has been updated since the process read it, the database engine discards its work and restarts the transaction logic. This restart is transparent to the application logic, which does not need to be coded to be aware of YottaDB transaction processing. This simplifies application code and improves maintainability. In the most common case, where a collision results from a random overlapping update by a concurrent process, it is able to commit on the second attempt.
+ - If the second attempt also fails to commit, the engine makes a third attempt, and if that fails, the engine concludes that pathological application logic is causing the collisions, and makes a fourth and final attempt during which updates by other processes are blocked, allowing the transaction to commit. [Applications should be written to avoid pathological colliding concurrent transactions; YottaDB provides tools and support services for application developers to identify such pathology should it occur.]
+
--- /dev/null
+---
+title: "Success Stories"
+draft: false
+---
+
+# Success Stories
+
+## University of Antwerp Library
+
+{{< figure src="/stands/yottadb/UoAntwerp_logo.jpg" alt="UoAntwerp Logo" width="50%" height="50%">}}
+
+YottaDB powers The University of Antwerp Library catalog, which includes 3.7 million copies of 2.4 million titles, and delivers fast response times and reliable access to users around the world.
+
+## Government Savings Bank
+
+{{< figure src="/stands/yottadb/GSB_logo.jpg" alt="GSB Logo" width="50%" height="50%">}}
+
+With 60 million accounts today, Government Savings Bank is one the largest financial institutions in Thailand, and a third of all Thais have an account at GSB.
+
+YottaDB’s performance and scalability allows GSB to process all 60 million accounts on a single real-time core system so that all transactions go straight through to the database of record.
+
+## Electronic Health Solutions (EHS)
+
+{{< figure src="/stands/yottadb/EHS_logo.svg" alt="EHS Logo" width="50%" height="50%">}}
+
+YottaDB is providing EHS the mission-critical YottaDB Support Services for EHS’ Hakeem Database Software. YottaDB’s performance and scalability allows Hakeem to process the medical records of patients in Jordan on systems that must be available wherever and whenever patients need care, i.e., across the entire country, with 24×7 availability.
+
+## Oroville Hospital
+
+{{< figure src="/stands/yottadb/Oroville_logo.jpg" alt="Oroville Logo" width="50%" height="50%">}}
+
+YottaDB supports Oroville Hospital’s VistA EHR implementation, running on the highly available and secure database engine.
+
+
+
--- /dev/null
+---
+title: "Use Cases"
+draft: false
+---
+
+# Use Cases
+
+## Internet of Things
+
+YottaDB fits the needs of real-time IoT systems that need to be “always on” because of its proven availability, reliability and security. Because it is highly scalable and multi-model, it can also handle the varying requirements of application data with ease.
+
+Plus, using a single database engine for the edge and the cloud simplifies application design and operational management, as well as allowing data to move seamlessly from one instance to another.
+
+## Health Records
+
+[M](https://en.wikipedia.org/wiki/MUMPS) is a de facto standard for implementing electronic health record applications, and the largest electronic health record systems in the world are written in M, dominating the segment as effectively as SQL dominates accounting and business applications.
+
+The YottaDB code base has its roots in healthcare as an implementation of M, with its first deployment at the Elvis Presley Trauma Center in Memphis in 1986. YottaDB includes an M language subsystem that is mostly compliant with, and extends the ISO/IEC 11756:1999 and ISO/IEC 15851:1999 standards. The YottaDB code base is one of the standard platforms for implementing VistA, ranging from small primary care practices and community clinics such as Oroville Hospital to Hakeem, an electronic health record system for an entire country.
+
+## Machine Learning and AI
+
+As a language-agnostic, multi-level, key-value database, YottaDB fits well with leading open source ML and data science libraries like H2O, TensorFlow, Keras, and Scikit-learn as well as commercial platforms like DataRobot and Dataiku.
+
+With support for SQL, Go, Perl, Python, Rust and other languages, plus JDBC access, YottaDB is ready for business-critical AI applications.
\ No newline at end of file
projects / stands-website.git / commitdiff