Show HN: SchemafreeSQL – Data, Fluid as Code
schemafreesql.comHi HN, I'm Dean, the non-technical co-founder of SchemafreeSQL. We released our beta version about a year ago. You can see the HN Post here https://news.ycombinator.com/item?id=30291592
Today I am pleased to announce our initial release of our hosted SFSQL offering.
A major concern from the HN Beta feedback we received was our longevity. Being a hosted database solution I can see why. We took that to heart and re-engineered our offering. We de-risked it by minimizing the amount of infrastructure under our management, fly.io manages customer's dedicated SFSQL endpoints, Aiven.io manages customer's dedicated databases across 5 clouds, our serverless offering is a managed AWS Aurora Serverless cluster, our in-house databases is managed by Planetscale.com, and Stripe handles subscriptions. The cost of these services are mostly on demand, bringing our monthly fixed cost to a very manageable level.
I highly recommend all these services.
We are boot strapping SFSQL for now. Our business model, how we make money, is simple. Our prices are higher than our costs. Just like all businesses, margins matter and because we incur the costs of these service and pass them on, our margins take a hit. We envision being more of an add-on to these service providers and others like them eventually. Our margins would increase and the total cost to our customers would decrease. In this model our pricing is purely value based.
"Data, Fluid as Code" is what we settled on after countless iterations. I believe it captures the "why" question, "why did we build this". SFSQL originally started out as an Object store for a online dev. environment we built in 2000. It has evolved over time. Its schemaless properties where added as we had a need to better handle user provided data structures and refactoring associated with many of our client projects.
Eric, the technical co-founder and creator of SFSQL, answered the "How" question in our HN beta post. For more in depth info on what's going on behind the scenes Eric is available via email support@schemafreesql.com, he is not available to respond here.
The demo apps were all built by me. Eric would like it known that he is not responsible for those codes bases, which are all available on GitHub. I built these apps while testing out SFSQL and seeing if we play nice with the various serverless platforms. Client solutions we have built with SFSQL are not available for public display so we went with these demo apps I built. The apps show how easy it is to hook up a back-end to a web app with SFSQL even by a non programmer like myself.
I hope you check out SFSQL. Try it for free, no sign-up required, and please leave us feedback https://schemafreesql.com/givefeedback_HN.html Having delivered projects with about a dozen different relational and "schemaless" databases over the course of 15 years, I'm proud to say I'm siding 100% with this article by now: https://orangematter.solarwinds.com/2015/02/24/schemaless-da... > There’s no such thing as a schemaless database. I know, lots of people want a schemaless database, and lots of companies are promoting their products as schemaless DBMSs. And schemaless DBMSs exist. But schemaless databases are mythical beasts because there is always a schema somewhere. Usually in multiple places, which I will later claim is what causes grief. When I started my career, I thought thinking about schema was an unneccessary complication that got in the way of me delivering valuable software. These days, I don't write a single line of code without having a good schema first, because it means I have understood the domain well enough to properly model it. I heard it put more succinctly as "schema on read" and "schema on write". "Schemaless" is really "schema on read" - you're making some assumptions about the structure/values you're reading out, and you plan to take specific actions based on those. "Schema on write" is... create db/table/column defs up front, and force the data adhere to that schema, so that when you read it out, there's no question about whether it conforms to expectations or not. Per the article you linked to, yes, there's always a schema. When/how you decide to verify the assumptions about the data is the question. This is true, but I want to point out that conventional DBMS DDLs are horrible schema definition languages, yet are placed at the center of schema design by the DBMS. They are horrible because because they hopelessly mix in all kinds of other concerns -- which is also why they are difficult to avoid. IMO, where a schemaless database like this would be useful is not to avoid having a schema, but to allow a clean source-of-truth schema to be used, independent of all of the other concerns related to data access and storage. (I'm commenting generally, BTW, not necessarily on this particular schemaless database.) SFSQL does have a rules API not implemented in our Hosted Offering. We have plans to enable it. You are correct there is a "schema" behind behind the scenes. Managing complex relationships between data and evolving those relationships can be a daunting task. SFSQL was created for that purpose. It's also true that database schemas cause problems (I don't mean as in "versus schemalessness") because knowledge of schemas gets embedded into code. but knowledge about db with schema is embedded in ... well schema. no? Your website feels like an infomercial. As an engineer, I went looking for some explanation of your language and how its grammar and semantics differ from SQL, but mostly I found a large jumble of JSON output and “demos”. The website is a about value proposition but if I have to dig into demo code internals to understand the product being offered, you’re asking a lot from me. Curious also why your co-founder is strictly off-limits and you’re building demos that he’s “not responsible for”. That gives a weird vibe too. I’m an enthusiast for SQL-like, join-free DB access and have a large appetite for weird/new ideas in this space, but after spending 10 min on the website on my phone, I gave up on satisfying my curiosity. The focus is on value prop. and yes the docs are lacking. Your feedback to include a comparison of our language to SQL is good. I was hoping the breakdown of the "shop admin" demo detailed the semantics of the language but looks like that it did not work for you. The thought was that by going through the examples with the free trial one could get up top speed with SFSQL, but maybe a more formal introduction to the language is needed. For reasons beyond our control Eric is not available for commenting at this time. He not wanting to take credit for the demos was more of a joke. Non trivial client work we have produced with SFSQL is not available for public review. I wanted public demos so I made them also to show how a novice can hook up a back-end with SFSQL sorry it came off as weird. Also sorry we could not peak your curiosity a bit more, we will do better. Compare your approach to EdgeDB - https://www.edgedb.com/. They have a similar product - SQL alternative but not NoSQL. Their homepage is also a little long, but has clear examples. Yes I see what you mean by "infomercial" when comparing SFSQL to EdgeDb. Was not our intention, its a work in progress. Will make the needed changes, thanks again for feedback. Why do people hate schemas so much? It is as silly as hating types in programming languages. It helps you to avoid doing stupid stuff. I have exactly the same feeling. Schema vs schemaless is like static typed vs dynamic language. The extreme is java vs JavaScript. With JavaScript, you have all freedom to construct objects with whatever properties, then you pay with hard-to-detect runtime errors. That is why people are going for TypeScript nowadays. I have learned this hard way, as I had hated Java so much sometime ago. For that I used quite bit Groovy, but later I had to refactor some with Java just for static typing, to avoid running time problems in critical area. I've been in PHP for a long time, and over the last 8-10 years there's been a push for more typing in the language, and we have a lot more typing ceremony than earlier PHP. The nice aspect is that you can get away without it, at least for a while, and add in later. By later I'm usually meaning minutes or hours, not months. :) Biggest example I can provide right now is writing a class method - I don't have to put a return type on a method (indeed, you couldn't in earlier PHP!). When I'm first writing a method, I don't always necessarily know how I might use it. I can write up something basic, then decide after testing/experimenting that I want the return type to be a float, not an integer. Did this in Groovy as well for a few years - not being required to declare a bunch of stuff up front let me focus on the internals/logic a bit more first. Once that was working, putting more explicit types in (return types, parameter types, etc) would help 'freeze' it in place. It's not hate it's differences in philosophies. You can sense the dynamics or tension between Eric(their techinical co-founder) and Dean,OP. There seems to be a very distinct separation like Eric will not answer questions on HN and Eric wants Dean to point out demo apps are not created by him (either it is credit issue or perceived lower quality issue). There is no we or us. When there is a strong trust or good team dynamics, there is no such strong indiviudal characteristics Eric and I have been together since 1997 solving problems with this thing called the Internet. Dynamics yes you can call it that. The comment was tongue and cheek about the code. Eric was unavailable to respond to comments in a timely manner so I let be known. Read into it as you want. Disclaimer: I'm not your target audience. I clicked on "The Solution" and saw this: We considered using: A SQL DB A SQL DB with a JSON Column Type A Document Store like Mongo All fell short. I thought that was uninformative. After leaving your site, I thought "maybe I could have clicked the items for more information". Sure enough, there was more information. However, I was then given items like "Create a 'brand' table". Is that a problem? Moreover, why would someone solve these problems using your product rather than an existing, known, and trusted NoSQL alternative? Are you giving the owner of a business a good enough reason to give you their money? This is a failure of the UI. I believe you clicked on "A Document Store like Mongo" and saw "Create a 'brand' table" which then goes on to explain why a document store does not adequately solve the problem The hope is that we are conveying a good enough reason to give us money. Thanks for you feedback