VelocityDB is a C# .NET NoSQL Object Database that can be Embedded/Distributed, extended as Graph Database is VelocityGraph.
Using VelocityDB saves time and money for all software requiring reliable, high performance data persistence. Any .NET object can be efficiently persisted and retrieved within ACID transactionalscope. The use of VelocityDB can be hidden from your application user's and doesn't require a lot of CPU usage or disk space.
What is OODB?
An object database allows software developers to develop application data models, store them as objects, and replicate or modify existing objects to make new objects within the object database system. The database is integrated with the programming language, allowing the developer to maintain consistency within one environment, since both the database system and the programming language will use the same model of representation.
Among other benefits, this architecture eliminates the need for a cumbersome mapping layer between the database model and the application data model.
In order to be fully productive with an object oriented database, you need to purge your relational database thinking and think object oriented, a good book about this is "Object Thinking".
Object vs Relational
A relational database stores all data in tables on a server. Clients talk to such servers using SQL statements such as "select * from actors". Data is also created and updated using SQL. VelocityDB is not a relational database (but it is very good at managing relations!), with VelocityDB C# objects are stored as objects with all references/relations between the objects. Using VelocityDB persistent C# objects is very similar to using in memory C# objects. Data is created by creating C# objects; updates are accomplished by updating C# objects. The persistent store is safely done using transactions with locking protection so that one user can't accidently undo other user's changes. Like most database systems, VelocityDB uses paging but unlike other systems VelocityDB data pages have variable size and can optionally be encrypted and compressed. VelocityDB persistent objects have an object identifier (Oid) consisting a DatabaseNumber-PageNumber-SlotNumber.
A detailed comparison between VelocityDB and a relational database can be found here as a pdf doc, as html here or original Word document here. This is a document under construction. Help us if you can.
Comparison with JSON document databases
Now compare this to how it is done with VelocityDB; Unlimited data types supported, almost any .NET data type can be persisted (one exception is Delegates as it involves code pointer data). VelocityDB uses a schema so that we can control what is stored. Any data, even unstructured, can still be stored as you can control how specific you make the schema. Having a schema enables serializing .NET object without having to describe each field data type, field name for each object stored. Redundancy is eliminated and objects can be used and stored as binary data with just the field values, not all its meta data, for each object. Having the schema gives structure that is used when constructing Linq queries. Support for object references is built in and only occupies 4 - 12 bytes in persistent storage. You can still use JSON when interacting with Web applications, Microsoft supports .NET object to/from JSON when used with frameworks such as Entity Framework. VelocityDB support import and export to/from JSON. Anything that can be done with a dedicated JSON database can also be done with VelocityDB. Simple comparisons between VelocityDB and JSON databases shows how performance and data size is affected by these differences. As data get larger these differences will increase. See comparison with MongoDB and Couchbase.