3 ms·

My name is Rick Negrin. I run the Product Management team at MemSQL, a scalable relational database. I recently wrote a blog on my thoughts regarding NoSQL vs.

by rickn 8y ago

My name is Rick Negrin. I run the Product Management team at MemSQL, a scalable relational database. I recently wrote a blog on my thoughts regarding NoSQL vs. Relational Databases and I'd love to hear the community’s thoughts on this.

deleted 8y ago
[deleted]
sqlcook 8y ago
Hi Rick, I've been following Memsql for a few years now, are there any plans to release "community" edition? Last time I checked about 1.5 years ago json support was very basic and EE pricing (dont remember exact #s) was rather high. Thanks
- siscia 8y ago
  What are you looking for in a "community" edition?
  - ddorian43 8y ago
    Something that you can use on production based on what your db advertises as it's advantages (high availability + sharding).
    - siscia 8y ago
      I was asking because I am the creator of RediSQL[1] -- SQL steroids for Redis -- which is a less sophisticated product than MemSQL but still has its own use cases. And maybe for parent was enough, or if not it would be very interesting to know what is missing. [1]: http://redbeardlab.tech/rediSQL/ http://redbeardlab.tech/rediSQL/
      - ddorian43 8y ago
        The same answer applies to your product.
        siscia 8y ago
        Honestly, I believe that for small workload you can definitely use RediSQL in production, it will happily contain your cache or it will be a great SQL database. However, I need a way to cut it between people just using the free product and people actually supporting the project, so provide as paying feature something that the big company will require it seemed to me the only way to go. Unfortunately, I don't have the capital nor the bandwidth to go with fully open source product and selling just support, which I don't believe is anyway a good business model. If you were in my shoes, you would do something different?
        jexah 8y ago
        I haven't followed any links posted in this thread, but some things I see often are: free for non-commercial use, timed commercial use usually in the region of 30 days, or rates based on reads and writes. The last one seems like a winner from what you've described as your situation.
        ddorian43 8y ago
        To be honest, I fail to see what I could use your product for so I'm out of the target audience. Assuming nosql is for something very efficient or very scalable, I need some space to use it before I have to shell $$. There are many products where I have to pay before going on production.
        siscia 8y ago
        It really depends on what you are building. If I were building a fast prototype I would not use a postgres box anymore but just a redis one. If you need to cache data in a way more complex than just key->value you don't have too many alternatives at the moment. If you want an easy and fast way to have an SQL engine in memory, again is not going to be simple. If you need a separated database for every of your user there are no many alternatives that I am aware of. It is definitely not a revolutionary product, but it has it's niche, any of the problems that I mentioned can be solved in a different way, but those different ways are quite complex.
    - siscia 8y ago
      EDIT: I couldn't reply directly to it's message, now I can, I just copied my previous comment verbatim below.
  - sqlcook 8y ago
    EE features without support. I hate to bring up Mongo as example, but something similar...where support, additional software/plugins and cloud hosting are where the $ is made. I did thorough testing of Memsql two years ago but went with Aurora instead. Would love to see how the product evolved since (Spark and Streaming integration was just being rolled out at the time), but something tells me pricing will be a deal breaker.
    - siscia 8y ago
      The point is that is not a convenient business model to just sell support, I can definitely understand why they are trying to sell features.
      - MarHoff 8y ago
        Thing is they are competing with PostgresSQL which you can extensively try for free before opting for a support. "Free" being already hard to beat. The fact that you can't extensively test a solution is a real turn down for me (unless negotiating with commercials which is not nerds cup of tea).
- berns 8y ago
  There already was a community edition[0]. And it was replaced by a "developer" edition that can no longer be used in production. It seems it didn't pan out as a marketing strategy and I don't think it's coming back. [0] https://news.ycombinator.com/item?id=9577663 https://news.ycombinator.com/item?id=9577663
AtlasBarfed 8y ago
I notice not a single mention of the CAP theorem. I have a hard time taking any "scalable" RDBMS solution seriously without a discussion on how you scale well-known problems with deletes and updates, maintaining b+tree indexes, distributed joins, distributed data, node loss/partitions, and distributed transactions/updates. If you are a new distributed system and don't have Jepsen tests or a similar level of discussion on how your database handles partition events, then that tends to be harbingers of snake oil in distributed systems. Granted I only did a quick search on CAP on your article, but the initial paragraph of your article didn't exactly invite further investigation or time investment. If your "NoSQL" is just a single node MongoDB, then you should state that rather than your blanket statement. As is your categorization of "NoSQL" is unspecified and unqualified, leading me to believe this is a management-level article with little regard for the real issues in large-scale distributed databases, and why would I think your software also considers such problems?

by rickn 8y ago

deleted 8y ago

[deleted]

sqlcook 8y ago

Hi Rick, I've been following Memsql for a few years now, are there any plans to release "community" edition? Last time I checked about 1.5 years ago json support was very basic and EE pricing (dont remember exact #s) was rather high. Thanks

siscia 8y ago
What are you looking for in a "community" edition?
- ddorian43 8y ago
  Something that you can use on production based on what your db advertises as it's advantages (high availability + sharding).
  - siscia 8y ago
    I was asking because I am the creator of RediSQL[1] -- SQL steroids for Redis -- which is a less sophisticated product than MemSQL but still has its own use cases. And maybe for parent was enough, or if not it would be very interesting to know what is missing. [1]: http://redbeardlab.tech/rediSQL/ http://redbeardlab.tech/rediSQL/
    - ddorian43 8y ago
      The same answer applies to your product.
      - siscia 8y ago
        Honestly, I believe that for small workload you can definitely use RediSQL in production, it will happily contain your cache or it will be a great SQL database. However, I need a way to cut it between people just using the free product and people actually supporting the project, so provide as paying feature something that the big company will require it seemed to me the only way to go. Unfortunately, I don't have the capital nor the bandwidth to go with fully open source product and selling just support, which I don't believe is anyway a good business model. If you were in my shoes, you would do something different?
        jexah 8y ago
        I haven't followed any links posted in this thread, but some things I see often are: free for non-commercial use, timed commercial use usually in the region of 30 days, or rates based on reads and writes. The last one seems like a winner from what you've described as your situation.
        ddorian43 8y ago
        To be honest, I fail to see what I could use your product for so I'm out of the target audience. Assuming nosql is for something very efficient or very scalable, I need some space to use it before I have to shell $$. There are many products where I have to pay before going on production.
        siscia 8y ago
        It really depends on what you are building. If I were building a fast prototype I would not use a postgres box anymore but just a redis one. If you need to cache data in a way more complex than just key->value you don't have too many alternatives at the moment. If you want an easy and fast way to have an SQL engine in memory, again is not going to be simple. If you need a separated database for every of your user there are no many alternatives that I am aware of. It is definitely not a revolutionary product, but it has it's niche, any of the problems that I mentioned can be solved in a different way, but those different ways are quite complex.
  - siscia 8y ago
    EDIT: I couldn't reply directly to it's message, now I can, I just copied my previous comment verbatim below.
- sqlcook 8y ago
  EE features without support. I hate to bring up Mongo as example, but something similar...where support, additional software/plugins and cloud hosting are where the $ is made. I did thorough testing of Memsql two years ago but went with Aurora instead. Would love to see how the product evolved since (Spark and Streaming integration was just being rolled out at the time), but something tells me pricing will be a deal breaker.
  - siscia 8y ago
    The point is that is not a convenient business model to just sell support, I can definitely understand why they are trying to sell features.
    - MarHoff 8y ago
      Thing is they are competing with PostgresSQL which you can extensively try for free before opting for a support. "Free" being already hard to beat. The fact that you can't extensively test a solution is a real turn down for me (unless negotiating with commercials which is not nerds cup of tea).
berns 8y ago
There already was a community edition[0]. And it was replaced by a "developer" edition that can no longer be used in production. It seems it didn't pan out as a marketing strategy and I don't think it's coming back. [0] https://news.ycombinator.com/item?id=9577663 https://news.ycombinator.com/item?id=9577663

AtlasBarfed 8y ago

I notice not a single mention of the CAP theorem. I have a hard time taking any "scalable" RDBMS solution seriously without a discussion on how you scale well-known problems with deletes and updates, maintaining b+tree indexes, distributed joins, distributed data, node loss/partitions, and distributed transactions/updates. If you are a new distributed system and don't have Jepsen tests or a similar level of discussion on how your database handles partition events, then that tends to be harbingers of snake oil in distributed systems. Granted I only did a quick search on CAP on your article, but the initial paragraph of your article didn't exactly invite further investigation or time investment. If your "NoSQL" is just a single node MongoDB, then you should state that rather than your blanket statement. As is your categorization of "NoSQL" is unspecified and unqualified, leading me to believe this is a management-level article with little regard for the real issues in large-scale distributed databases, and why would I think your software also considers such problems?