Over the last several months, I’ve been doing qualitative research into the coding school / developer education space. Specifically investigating if, how, and why coding programs incorporate databases into their curriculum. While there were of course some differences based on location, size, and emphasis, there were also a few interesting commonalities. I thought I’d share my findings, see if the community has additional insight, and highlight where HarperDB might fit into the mix. (Note: this is related to frontend and full stack programs since backend programs focus almost entirely on databases.)
Findings
To conduct this research I reached out to numerous coding instructors, educators, and students across the U.S. and Canada. While many people were respectively too busy, several folks were generous enough to share a bit of insight via email or hop on a call to have a more in depth discussion (if those folks are reading this - thanks again for your help!). I learned the following insights:
- In general, most coding bootcamps, programs, or classes do touch on databases.
The extent or time spent on databases as well as the variety of databases included depends on the length of the program as well as size - no surprise here. While the larger programs might have more time to touch on databases, they may not have the flexibility to deviate from or influence the course catalog. Whereas smaller programs tend to have more flexibility to switch up the curriculum instead of having to “cut through red tape” to make a change.
- Generally the same few databases were included in coding curriculums across the board, depending on the focus of the program and location: MongoDB, PostgreSQL, and SQLite.
Smaller / shorter programs that don’t require modeling tend to use MongoDB, while larger / longer programs tend to use PostgreSQL because you can do more with it.
- Main requirements or road blocks of incorporating databases or making changes to the curriculum? What influences which databases are included?
One of my favorite quotes was, “If something is pretty hot out in the wild, it will find its way into a classroom pretty quickly.” However, some of the larger or more established schools have more restrictions when it comes to making changes. One lead educator at an established school mentioned that these programs are licensed by the state they're in, and changing them can be expensive and exhausting. Instructors can teach certain things "off the books," but if they don't teach what’s in the course catalog they risk being fined or sued.
Also not surprising, some of the smaller schools or full-stack focused programs (as opposed to strictly relational for example) have a lot more flexibility with what databases they teach and when they want to switch it up. (But there were some outliers here as well!) One major commonality in how schools choose which database to teach is the local job market, as well as whichever tool will enable instructors to get from point A to point B in the smoothest way possible (i.e. no old-school clunky systems that take forever to install and learn!).
An instructor from another well-known program said “Our curriculum is flexible, we’re always changing technologies and structure- we adjust if the current is going elsewhere. We’re currently using Mongo because so many new companies are using NoSQL, but I still see the importance of SQL and can see value in including it as well.” Yet another coding instructor stated, “The main requirements for incorporating new databases is easy to follow documentation and examples of it working in a full stack app using Python or some other language. We use technologies as long as they have value in the job search.”
Key takeaways here:
If it were up to teachers, the curriculum would probably be updated every couple months or so. (But this can certainly be a complicated process, and many programs only make major changes every couple years). Generally the databases included in coding curriculums are dependent on current “trends” (with mixed reviews on who determines these trends), ease of use, and functionality relative to the real world.
Why HarperDB Could be a Fit for Coding Schools
- User friendly, flexible, intuitive
- Quick & easy - up and running in minutes
- Free managed service w/ HarperDB Cloud
- SQL & NoSQL in a single product - save time, best of both worlds
- Hooks & extensions, real world examples & SDK’s
- Management Studio / GUI
- Language agnostic
“I will definitely be covering Harper in my college class. The 'blending' of SQL and NoSQL is cool. I like Mongo-style NoSQL database architectures, but prefer SQL statements for CRUD. It's a great way for the students to be exposed to both styles.”
-Manav, Full Stack Developer & Instructor
The main reason I embarked on this research journey was because several HarperDB users came back to our team and said, “Wow, I could actually see this being a great tool for coding schools / new developers.” Of course I’m writing this because I now understand why this is true, and I’m glad that I was able to make some awesome connections along the way!
It seems only fair to start with a feature that really makes HarperDB stand out among others - NoSQL and SQL functionality, including joins, in a single product (whereas other solutions might include integration headaches and data duplication just to achieve SQL capabilities). Our dynamic schema and storage algorithm enable HarperDB to ingest any type of data at scale. So for example, you can ingest NoSQL data and run SQL queries on it immediately. For instructors and students that don’t have much time to spend teaching or learning several systems, you can really cover all your bases with HarperDB. Are you a SQL only program? No problem! HarperDB follows ANSI SQL standard enabling SQL on JSON, and if students decide to dabble with NoSQL on their own time they’ll already be equipped with the right tool.
HarperDB was built by developers for developers. Our goal is to literally be the most user friendly database out there - and it was consistently designed with this in mind. Users can be up and running in minutes; HarperDB Cloud is managed and hosted so you won’t have to deal with big classes having issues with installation. HarperDB has clear documentation, video tutorials, and tangible developer examples to guide the way. The intuitive Management Studio enables users to install, design, cluster, and manage databases without writing a line of code in one sleek interface. You can insert JSON, CSVs, or via SQL with a simple to use, single endpoint REST API. Code examples are available in the Studio in most languages. Additionally, our team loves to hear from users, and support is consistently available if you get stuck, have questions or feedback, or simply want to connect with the HarperDB community.
Some additional comments from educators on HarperDB:
“I really enjoy how HarperDB docs are structured, I could see this being a no-brainer for someone just learning to code.”
“I could see the HarperDB advantage of not having to change much of the program to cover what we do, no intermediary necessary.”
“In theory we could teach with this and expand upon the aspects we teach with our current database.“
“If HarperDB has parallels to Mongo and is more approachable, maybe this could be an alternative… a good way to show what a REST is, then build your own API, and incorporate SQL as needed.”
“We are always trying to expand our offerings to students, especially given the expansion of cloud services across the board.”
“A pain point from students is when they split between two technologies between SQL/NoSQL.”
“I’m a big fan of hosted and free tier. Code examples and packages with programming languages are helpful as well.”
Comparisons in the Market
A quick note on how HarperDB compares to some of the databases being taught in the classroom today:
MongoDB: Mongo is great for certain use cases, but we found that HarperDB is 37.9x faster at less than 1/2 the price. HarperDB has a native REST API, supports SQL on JSON, and can be easier to use and manage. See the benchmark here.
PostgreSQL: HarperDB is more flexible than PostgreSQL, which is a great database, but HarperDB has simplified much of the work on installation and configuration. HarperDB is allowing developers from relational backgrounds to use their existing knowledge with SQL with a database that also allows their team to use NoSQL from the same data model.
SQLite: SQLite is a good product but is not sufficient for high volume and high transactions. The benchmark found that HarperDB outperformed SQLite on all test cases, and was 581% faster on average.
So, is it time to try something new?
Change is not for everyone, and I’m a big believer of the adage “if it ain't broke don't fix it.” However, let’s remember that this is the tech industry, and it’s important to stay ahead of the curve, continuously introducing the modern solutions that have greater functionality in a smaller package. There may be some barriers to change, but there’s almost always a loophole as well.
For example, it seems that while some coding schools may have predetermined databases outlined in the catalog, the students still have the freedom to use any technology they’d like for their projects as long as they follow the general guidelines. For those schools that tend to be more flexible or open minded, it’s up the individual instructor or curriculum developer’s discretion as to when they incorporate a new database in their teachings. Of course there are certain use cases where MongoDB or PostgreSQL might be the better choice, but when it comes to things like quick and easy install, rapid app development, user-friendly resources, etc., I can see why some of these instructors and students are giving HarperDB a shot in the classroom.
My research indicated that as students search for jobs, the market is highly skills focused and not as focused on experience with a specific tool or database, and HarperDB is enabling you to learn more skills with less tools.
Lastly, if I haven’t sold you yet on trying something new, a couple of the students that I connected with said that incorporating more classes on databases in general would have been helpful when they were in coding school. Now, we know that some of these programs are too short and simply don’t have the time to add material. However if you were going to add even one day on databases, it seems you would want to go with a beginner friendly database that has diverse / hybrid functionality instead of trying to teach three different systems in one day! What are your thoughts?
PS- Looking for resources on learning how to code outside of coding school? Check out the best places to learn to code for free or Juni's best Javascript projects for kids.
Top comments (20)
It's necessary to learn database types and try at least one of each.
Back those days I learned MySQL and SQL Server, on an era where you could connect a Microsoft Access DB to a web monolith to sync local changes with remote changes because it was a trend and an easy way to go to deal local software (DB Forms and views) plus online tools such e-commerce and so.
Nowadays that workaround is forbidden for obvious reasons and you need to know at least a relational database such MySQL/MariaDB and maybe some about mongo and Postgre, knowing a bit that three options while deep learning one of them lets you work with any of the existing on the market.
Neither it's necessary to be those three exactly, you can pick up another one of each type of course.
BTW and answering the title you need to know about databases for many reasons, one of them being the need of having one on the 99,99% of the projects and the second one being the knowing about data storage and implications it has when developing software. When you learn about your language and the database it's used on your project you can code things efficiently.
Also the major part of us are full stack but specialized on either back or front end (I think there are no senior devs uncapable to code a web app using back and front + DB + server config combined) so sometimes you'll need to throw a query directly into production DB to fix something, or perform queries to get data or aggregated data to get some BI related stuff at business level on a manner or another.
I'm supposed to be in front end but I solve database related tasks almost every day and I put my hands on back end development several times a year, and it's like this since I started coding professionally so I would say it's a must
Thanks for sharing Joel, this is very insightful. I like your point about knowing just a couple of the database options out there, while having a deeper understanding of at least one, will set you up to work with any of the existing DB's on the market. If you ever end up checking out HarperDB, we'd love to hear your thoughts! :)
Is it something new? Didn't heard about it till now
HarperDB has been around since 2017, and we released HarperDB Cloud (our DBaaS) about 6 months ago.
Oh I understand. Do you have driver and API for any language or it works as a service only?
Yes we have a REST API so we are language agnostic, and we have traditional drivers and interfaces. We have example code in the Management Studio available in most languages.
Nice I'll take a look :)
I saw pricing depending on RAM, does CPU also scale proportionally? Can you set up auto-scale to avoid service saturation when some campaign is set up or do you have to control it manually?
Also if I need 32 or 64Gb for 2 days or a week do you charge me with monthly cost of 64 Gb even when usually running ok with 8Gb?
HarperDB Cloud managed instances run on provisioned Amazon EC2 instances. The CPUs scale proportionally as well, you can read more about the instance hardware specs here. HarperDB Cloud does not currently offer autoscaling, but you can manually scale instances. Because instances are single tenant, you always have reserved capacity and will be billed for the monthly cost of your instance.
So what is the benefit against GCP or AWS?
I understood the API thing but nothing that can't be provided easily by my own (speaking from the business point of view)
I'm not sure I fully understand your question here, maybe that you don't need an SDK? If you'd like, it might be easier if we start a direct chat here on Dev so we can have quicker back and forth. Or feel free to shoot me an email margo@harperdb.io
Thanks Joel!
well the purpose of keeping it as thread is to answer possible questions others could have too.
I mean that If I set up an API let's say using PHP + MySQL I can use Laravel and benefit from the ORM plus isolating on that instance the microservice/service related code and DB.
I can set it up on an Amazon EC2 which will be cheaper than relegating the DB stuff to harperDB, isn't it?
Also the ORMs usually don't work through REST calls but connecting itself into a DB instance.
I'm trying to balance costs of development with costs of architecture comparing that to what it could be using it. Also I'm trying to understand what can HarperDB offers me that I can't get with Google Cloud Platform or Amazon Web Services "as is" or at low cost (few hours of a programmer)
An ORM is not necessary with HarperDB, as the primary method of interaction is through the API. This does not add any overhead to the application, in fact, it removes a layer from your application stack because HarperDB natively returns JSON objects.
Additionally, HarperDB can be installed wherever you'd like. We offer a DBaaS product, HarperDB Cloud, but you can also find HarperDB on npm.
I think you've not internalized what an ORM is but anyway I'll take a look for another stuff i've in mind it can work well with some controller or gateway or without that depending on the possibilities of Harper :D
Thanks for answering
Sounds good Joel, please let me know if any additional questions come up or you can always connect with our team on the Community Slack! :)
Databases are an essential layer of the stack and thus should not be forgotten!
I think databases should be taught because when you start to learn them you will realise that they are not that hard to learn. When people keep them outside of a curriculum they give off the impression that it's a technical subject to understand.
I used HarperDB and PostgreSQL to create an app recently posting the tutorial later.
Agreed - great insight Andrew! Really looking forward to seeing what you built with HarperDB and PostgreSQL.
At Lambda I truly learned the full stack, not necessarily just in the curriculum, but we got a thorough breakdown of the fundamentals and then had a chance to out that to the test with sprint challenges qeekly as well as build weeks at the end of each unit that a team worked on, that team consisted of one student from each unit together to use their skills they've learned to that point to build a full stack app, and that in itself is truly rewarding. I learned both PostgreSQL/SQLite and MongoDB/mongoose for various projects depending on its needs.
The only thing that keep me using SQLite, is that it is the only decent embedded database with bindings in most languages.
It seems that embedded database development isn't really cared about, compared to an explicit web server.
Also, I am worried that HarperDB still couldn't provide the security of prepared statement... (Actually, MongoDB also has this problem as well, when strings start with
$.)