index.html

---
layout: layout
title: Start
---
<div class="splash">
	<h2><img src ="images/memstate-logo-inverted.png" height="52" style="vertical-align: middle;"/> <img src="images/memstate-logo-text-inverted.png" height="52"></h2>
	<h3>In-memory OLTP for .NET 
		<br />
		<i>Build faster systems, faster</i></h3>
		<a class="github-button" href="https://github.com/devrexlabs/memstate" data-show-count="true" aria-label="Star devrexlabs/memstate on GitHub">Star</a>
</div>

<div class="well large container-fluid">
	<div class="row">
		<div class="col-md-2"></div>
		<div class="col-md-8">
			<h1><em>Build faster systems, faster</em></h1>

			<p style="line-height: 1.7">
					Moving data back and forth between disk and RAM is extremely inefficient. In a traditional
					layered backend architecture, most of the code is there to deal with this 
					Memstate is designed from the ground up to run in-memory and 

					Use Memstate to structure and manage your data in-memory, obtain transparent persistence, concurrency control
					and transactions with strong ACID guarantees. Make your applications 100x faster, and your developers

					Memstate has many possible use cases but is designed primarily
					to handle complex OLTP workloads in a typical enterprise application.
			</p>
			<p style="line-height: 1.7">
				Memstate enables you to build high quality, mission critical
				systems with real-time performance at a fraction of the time and cost.
			</p>
		</div>
		<div class="col-md-2"></div>
	</div>
</div>

<div class="well-large container-fluid">
	<style>
		h2 {
			margin-top: 2em;
		}
	</style>
	<div class="row">
		<div class="col-md-4">
			<h2>100x performance</h2>
			<p>
				In-memory operations are orders of magnitude faster than disk operations.
				A single Memstate engine can execute millions of read transactions 
				and tens of thousands of write transactions per second, all at submillisecond latency. 
			</p>
		</div>
		<div class="col-md-4">
			<h2>10x developer productivity</h2>
			<p>
				This is the #1 reason we built Memstate. The traditional backend architecture has so many complex parts and
				layers that can be eliminated when using an in-memory centric architecture. The traditional RDBMS backend developer needs to deal with
				data access, relational modeling, object-relational mapping, data type conversion, sql tuning, caching, migrations and transaction
				management to name a few things. 

				With Memstate, a single in-memory domain model replaces the domain layer, data access and data layers.
			</p>
		</div>
		<div class="col-md-4">
			<h2>Software quality</h2>
			<p>
				Memstate transactions are 100% ACID out of the box. Commands execute one at a time, transitioning the in-memory
				model from one consistent state to the next. The data model, commands and queries are all strongly typed,
				compile-time checked, version controlled with the rest of your code and easily unit tested.
			</p>
		</div>
	</div>
	<div class="row">
		<div class="col-md-4">
			<h2>Bring your own data model</h2>
			<p>
				Memstate in-memory data models, commands and queries are written in C#.
				Create your own domain specific model, or use one of the built-ins:
			</p>
			<ul>
				<li>Relational</li>
				<li>Document</li>
				<li>Key/value</li>
				<li>Graph</li>
				<li>Xml</li>
				<li>Redis clone</li>
				<li>Message Broker</li>
			</ul>
		</div>
		<div class="col-md-4">
			<h2>Real-time</h2>
			<p>
				sub-millisecond latency
			</p>
			<ul>
				
			</ul>
		</div>

		<div class="col-md-4">
			<h2>Modular architecture</h2>
			<p>
				Memstate can easily be customized to meet your specific requirements.
				Choose from existing modules or implement custom plugins.
				Storage and wire formats:
				<ul>
					<li>JSON</li>
					<li>Wire (binary)</li>
					<li>Protobuf (planned)</li>
				</ul>
				Backing stores:
				<ul>
					<li>Event Store</li>
					<li>PostgreSQL</li>
					<li>Local filesystem</li>
				</ul>
			</p>
		</div>
	</div>
	<div class="row">
		<div class="col-md-4">
			<h2>Time travel</h2>
			<p>
				The command journal contains a complete history of every change ever made to the data.
				This means that: 
			</p>
			<ul>
				<li>Data can be restored to to any point in time</li>
				<li></li>
				<li>You know exactly who did what and when</li>
				<li>Software engineers can go back in time and se</li>
			</ul>
		</div>
		<div class="col-md-4">
			<h2>Not just .NET</h2>
			<p>
				The HTTP Command/Query API lets any client that can speak HTTP
				execute commands and queries.
			</p>
		</div>
		<div class="col-md-4">
			<h2>Simple management</h2>
			<p>
				Easily administer Memstate Server using a simple and intuitive web-based interface.
			</p>
			<ul>
				<li>Monitor, start and stop nodes</li>
				<li>Manage replication</li>
				<li>Execute ad-hoc queries</li>
			</ul>
		</div>
	</div>
	<div class="row">
		<div class="col-md-4">
			<h2>Open Source and free</h2>
			<p>
				Memstate is fully open source and licensed under the LGPL license. The source code is hosted on <a href="https://github.com/devrexlabs/memstate">Github</a>.
				Memstate is free to use for both commercial and non-commercial purposes.
			</p>
		</div>
		<div class="col-md-4">
			<h2>Runs on Linux, MacOS and Windows</h2>
			<p>
				Memstate is based on .NET Standard 2.0 and runs on .NET Core >=2.0, .NET Framework >=4.6.1 or Mono >=5.4.
			</p>
		</div>
		<div class="col-md-4">
			<h2>High availability</h2>
			<p>
				Memstate supports any number of read/write replicas, just connect to 
			</p>
		</div>
	</div>
	<div class="row">
		<div class="col-md-4 col-md-offset-2">
			<h2>How does it work?</h2>
			When the memstate engine starts, the in-memory model is restored by replaying all
			of the commands in the command journal. When the model is ready the engine
			starts processing commands and queries. Commands are sent to the underlying storage provider
			
			
		</div>
		<div class="col-md-4">
			<h2>So what's the catch?</h2>
			<p>
				Here are the major drawbacks:
				<ul>
					<li>The command journal, unless truncated, can become large over time</li>
					<li>Truncating the journal erases the history of events</li>
					<li>Snapshots take time to read and write</li>
					<li>System is readonly while snapshot is being taken</li>
					<li>Bringing a large system online can take time</li>
				</ul>
			</p>
		</div>
	</div>
</div>