[HN Gopher] Show HN: SchemafreeSQL - Data, Fluid as Code
___________________________________________________________________
Show HN: SchemafreeSQL - Data, Fluid as Code
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 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
Author : dfragnito
Score : 28 points
Date : 2023-03-10 20:10 UTC (3 days ago)
(HTM) web link (schemafreesql.com)
(TXT) w3m dump (schemafreesql.com)
| jitl wrote:
| 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.
| dfragnito wrote:
| 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.
| jitl wrote:
| 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.
| dfragnito wrote:
| 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.
| [deleted]
| endymi0n wrote:
| 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.
| cryptonector wrote:
| 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.
| dfragnito wrote:
| 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.
| mgkimsal wrote:
| 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.
| [deleted]
| bachmeier wrote:
| 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?
| dfragnito wrote:
| 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
___________________________________________________________________
(page generated 2023-03-13 23:02 UTC)