Attending MongoDB World in NYC?

Hi folks,

I've been quiet for a long time since I last wrote.
The last several months were exciting times for me in many fronts.
I took some time to stay away, get some breath, retune and refocus.

I have taken a super-exciting opportunity with Cisco, joined a startup within the big corp, running separately, running fast, located in Cambridge MA, at the heart of where all innovation is happening.

We're developing a new paradigm in the management of security appliances, from the cloud with a lot of analytics, wisdom and science around it.

I get to do a lot of creating, architecting and engineering around these same things I love, data and databases, and with an awesome group of super-talented people around me. Living the dream! :)

If you are in New York on the beginning of June, come over to MongoDB World conference!
And while you're there, make sure you come and hear what I have to say in my session "Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS Application"

Monday, June 1, at 11:40.

Use the code SpeakerFriend for a 15% discount at http://www.mongodbworld.com!!

See you at #MongoDBWorld!!

How Elasticity is dictated by Data Model?

I talk a lot about "Elasticity" and "Data Model", a prospect asked me today "what makes you think they are related?".

Not only are they related, the relation between them holds big part of the substance of ScaleBase, the technology I've been working on for the last 5 years...

Elasticity is the ability to grow or shrink in accordance to the demand.
The cloud makes it very easy to spin more machines, on demand and kill them a day after, pay by the hour, only for real usage. This alone offers fantastic elasticity. Remember that AWS's EC2 stands for "Elastic Compute Cloud".

Volatile/transient/stateless servers are easier to make elastic, AKA application servers, web servers. Just spin another same-image-server behind a round-robin load balancer would solve 80% of the problem.

Data is harder to "elastify".

1. Data can be replicated across multiple identical servers behind the same round-robin load balancer, but data-replication multiplies data size (bad ROI) and cannot scale writes and updates to the data. 
2. The only way to scale data is to have it distributed across multiple non-identical servers. 

New challenges:

1. How would all data consumers (apps, tools) know where the data they look for resides? 
2. If all for every access they need data from several (or all) the servers, load will end-up multiplied rather than distributed. = no scalability.
3. OK not all or most, but the minority of accesses do need data from several (or all) the servers. How this data can be found on all quickly and aggregated? 

Challenge 1 is the simplest, just have an index expressing "I want to distribute my data by profile_id" and "put profiles 1-1000 on db1 and 1001-1500 on db2", and then force all data consumers check this index before every data access.

Challenges 2 and 3 are where data model kicks in. For NoSQLs, data model is a document, complete and self-contained, challenges 2 and 3 do not exist.
For SQL databases, a relational data model, takes challenges 2 and 3 to the extreme.

A carefully crafted data distribution policy and the ability to do real-time data aggregation are crucial for a successful scaling relational database.

In our profiles distribution example, identifying that "a profile" is actually a chunk of related data from 100 tables in a complex, multi-level, deep hierarchy - is a hard task to do.
ScaleBase Analysis Genie simplifies the authoring of a data distribution policy that makes sure that related data is stored together on the same server, solving challenge 2.

ScaleBase Controller employs multi-threaded massive parallel execution and advanced result aggregation, supporting all SQL aspects including support for GROUP BY, ORDER BY, HAVING, UNION, JOIN, SUBSELECT to solve challenge 3.

See here for more info: http://www.scalebase.com/products/product-architecture

Will AWS plans for PostgreSQL RDS help it finally pick up?

"Amazon to add Postgres to its most-favored database list" says GigaOM:

http://gigaom.com/2013/11/12/amazon-to-add-postgres-to-its-most-favored-database-list/

"To many this is no-brainer. Amazon wants to support the databases that its developer audiences want to use. This is simply a  case of Amazon responding to user demand and oh-by-the-way making its cloud infrastructure more attractive to a specific target audience. Some say Postgres has gained traction since Oracle’s acquisition of MySQL via its Sun buyout a few years back."

Some people I know said "yea, the writing was on the wall...". Well, was it?? Really? 

AWS finally got the time to "plan" for supporting Postgres now? After supporting MySQL, Oracle and SQL Servers for almost 3 years?! Writing was on the wall? Where can I find a wall this old?

PostgreSQL has not picked up. 

This is why it is a far 4th on Amazon's list. The writer of the text above also makes clear efforts not to pick a side here... "to many this is a no-brainer" or "some say Postgres has gained traction". 

It has been around for ages, thru many "oh! it's now happening!" events, such as the acquisition by of MySQL by Sun, then by Oracle... 

Technically, PostgreSQL's few superior capabilities, especially around schema online modifications (which gets more important these days!), probably could not change its fate, and it's still being held back by too many inferior capabilities, around performance, robustness, ecosystem... 

So - with plans for RDS, will Postgres now pick up? 

Feel free to Share your thoughts...