Hi 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 <a href="https://news.ycombinator.com/item?id=30291592" rel="nofollow">https://news.ycombinator.com/item?id=30291592</a><p>Today I am pleased to announce our initial release of our hosted SFSQL offering.<p>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.<p>I highly recommend all these services.<p>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.<p>"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.<p>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.<p>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.<p>I hope you check out SFSQL. Try it for free, no sign-up required, and please leave us feedback <a href="https://schemafreesql.com/givefeedback_HN.html" rel="nofollow">https://schemafreesql.com/givefeedback_HN.html</a>
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:<p><a href="https://orangematter.solarwinds.com/2015/02/24/schemaless-databases-dont-exist/" rel="nofollow">https://orangematter.solarwinds.com/2015/02/24/schemaless-da...</a><p>> 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.<p>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.
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”.<p>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.<p>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.<p>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.
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
Disclaimer: I'm not your target audience.<p>I clicked on "The Solution" and saw this:<p>We considered using:<p>A SQL DB<p>A SQL DB with a JSON Column Type<p>A Document Store like Mongo<p>All fell short.<p>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?<p>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?