> * Nimbus implements the semantic data model where on table can be
> defined to "extend" another. A record inserted in extended table is
> also visible in the parent table, albeit with fewer attributes
> * Nimbus supports unbounded types. Fields can be declared as type
> "string" or "number" rather than "varchar(37)" or "short int".
> * Nimbus supports UTF8, period. Character set conversion is a client
> issue. It does, of course, support collations.
> * Nimbus will support an open ended set of aggregating interfaces,
> so a single round trip to the server can return the results of many
> queries

The discussion so far has been focused on your physical (scaling, lag) goals, but you also seem
interested in some logical (model, datatype, interface) improvements over existing RDBMS's. Is that
something you're also interested in discussing here, or would you (or other list members!) rather
avoid turning this into a feature-request-fest? If you're going to start from scratch anyway ...

As to disks: large-capacity solid-state disks are coming onto the market nowadays; they're still
expensive, and they're certainly not as fast as actual RAM, but they're still a marked improvement
over traditional platters. Is there a proof that 'durable' media will always be the bottleneck? We
may some day soon all switch to UPS-powered RAM drives and declare those sufficiently-guaranteed to
be 'durable' for the purposes of the 'commit' contract ...

You could also look into using CAM (content-addressable memory, O(1) searches) for common lookups,
if such memory is available on the host -- I could see future database servers shipping with some
CAM, if software existed that could actually use it. I've only heard of it being embedded in custom
hardware/software solutions (e.g. expensive Cisco equipment), so I don't know how that would play
with general-purpose OS's, POSIX API's, etc.

-Philip