click to visit home page
leading the way to the new storage frontier .....
image shows software factory - click to see storage software directory
SSD software ....
memory channel storage
memory channel SSDs ...
M.2 SSDs ..
image shows megabyte waving the winners trophy - there are over 200 SSD oems - which ones matter? - click to read article
top SSD companies ..
SSD SoCs controllers
SSD controller chips ..


Founded by embedded database and real-time systems experts, McObject offers proven data management technology that makes applications and devices smarter, more reliable and more cost-effective to develop and maintain. McObject counts among its customers industry leaders such BAE Systems, Siemens, Phillips, EADS, JVC, Tyco Thermal Controls, F5 Networks, CA, Motorola and Boeing. McObject, based in Issaquah, WA, is committed to providing innovative technology and first-rate services to customers and partners. The company can be reached at +1-425-888-8505, or visit

see also:- McObject's paper - In-Memory Database Systems: Myths & Facts

editor's comments:- McObject is in the SSD software market ecosystem and among other things markets in-memory database systems for deployment in applications ranging from small footprint embedded appliances upto Terabyte scalable in memory databases for high availability enterprise servers.

This was once regarded as a specialist performance driven market but since the advent of DIMM wars and the availability of terabyte tiered memory in DIMM sockets originally designed for DRAM - the adoption of big memory software is trickling down to all markets and will become mainstream.
McObject mentions in SSD market history

In November 2012 - McObject announced that it has run benchmarks of its intrinsically designed for in-memory database systems software - with transaction logging enabled - on a number of different devices - and in particular Fusion-io's ioDrive SSDs.
SSD ad - click for more info

selected SSD aricles on

the SSD Heresies

SSD controllers & IP

Can you trust SSD specs?

this way to the petabyte SSD

the 3 fastest PCIe SSDs list(s)

Surviving SSD sudden power loss

what do enterprise SSD users want?

Where are we now with SSD software?

how fast can your SSD run backwards?

The big market impact of SSD dark matter

flash SSD capacity - the iceberg syndrome

Adaptive R/W flash care & DSP ECC for SSDs

Why size matters in SSD controller architecture

Efficiency as internecine SSD competitive advantage

7 SSD types are all you need in the solid state datacenter
SSD ad - click for more info

storage search banner

"It's clear now why it take so long
for the software industry to
wake up to the idea of SSDs."
where are we now with SSD software?
in memory database is even better with FIO's flash SSDs
Editor:- November 19, 2012 - McObject today announced that it has run benchmarks of its (intrinsically designed for) in-memory database systems software - with transaction logging enabled - on a number of different devices - and in particular Fusion-io's ioDrive SSDs.

Editor's comments:- In a paper published 3 years ago - In-Memory Database Systems: Myths & Facts - McObject said that fast flash SSDs used as the storage hot spot for traditional database software could never get performance as good as their own in-memory solution running in DRAM with legacy hard drive array bulk storage - and various remarks in that paper sent out a strong anti-SSD message which the company is in effect correcting today.

What McObject is now saying - is that by using a fast low latency SSD for the "performance draining" transaction log - you can get even greater speedups. There are other benefits too - which arise from the efficiency of their small footprint database - which means that a software product - which was originally designed for the DRAM-HDD world - is a good fit in the flash SSD world too - if you have the right scale of data and the right SSD.

...Later:- McObject's Marketing Director Ted Kenney emailed me to clarify a couple of points about their product and my interpretation of their business thinking. Here's some of what he said.

I would point out one thing about your blog post, just to clarify from McObjects point of view.

You mention the Myths & Facts white paper, specifically where we argue (Myth 3, I believe) that an IMDS will always be faster than an on-disk DBMS that uses an SSD to store records.

Keep in mind that that papers comparison does not touch on transaction logging. At least, transaction logging is not mentioned; the assumption (our assumption, in writing it) is that the comparison is between a pure IMDS (all data kept in main memory and nothing stored to persistent media), and an on-disk DBMS that stores records on a SSD. Our conclusion was that while the DBMS storing to SSD is likely faster than a DBMS storing to HDD, it still cant touch the performance of a pure IMDS.

In contrast, our recent comparison (the subject of the press release I sent you) is focused differently: it presumes that the user wants data durability and recoverability. That rules out use of the pure IMDS (because RAM storage is volatile), so we instead look at solutions that deliver recoverability/durability, specifically an on-disk DBMS storing records to persistent media vs. an IMDS with transaction logging (lets call that IMDS+TL). Then for the IMDS+TL we measure performance using different storage devices: HDD, SSD and ioDrive.

The result: an IMDS+TL storing its log on HDD beats the performance of a DBMS storing records to HDD (by about 3x). If you then upgrade the device on which the IMDS+TL stores its transaction log, the performance difference (compared to DBMS+HDD) is even greater (as much as 15x when using the ioDrive). But the recent round of testing did not look at the pure IMDS performance. If it had, the pure IMDS would have beat the IMDS+TL using any of the devices to store its transaction log.

We hadn't considered that our message in the earlier white paper was anti-SSD or that we we're now correcting that message. Instead, wed say that the earlier paper looked at a scenario in whichperformance is the highest goal (the only goal mentioned, anyway) whereas the new tests focused on performance, with durability/recoverability as an additional requirement.

Re your comment - It seems that a software product which was originally designed for the DRAM-HDD world is a good fit in the flash SSD world, too if you have the right scale of data and the right SSD. - Actually eXtremeDB was designed for the DRAM world initially (in-memory only). When we later added support for persistent storage (first with transaction logging, later with optional persistent storage for selected record types) we were (and still are) agnostic: eXtremeDB does not recognize or care about the type of persistent media used.

Again thanks for taking the time to look at our news and at our various statements vis-à-vis flash, storage and performance. It sounds like you understand our technology and the issues involved. I just wanted to point out that the white papers discussion, and this recent press release, take slight different perspectives on what the developer/end-user is trying to accomplish.